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	(Smail3.1.28.1 #3) id m0quQcz-0000mBC; Mon, 10 Oct 94 14:43 CDT
Received: from gateway1.ATK.COM by ATK.COM (5.65/1.34)
	id AA06809; Mon, 10 Oct 94 14:43:12 -0500
Message-Id: <9410101943.AA06809@ATK.COM>
Date: 10 Oct 1994 14:51:40 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
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                       Subject:                               Time:2:33 PM
  OFFICE MEMO          HF Digital Bibliography                Date:10/10/94
Someone on the Ham Digital newsgroup was looking for info on PACTOR the other
day.  This prompted me to go through my files and prepare a bibliography. 
This was limited, for the most part, to the ham periodical literature.  I
specifically excluded professional journals and books as these can be easily
located through normal liberary research techniques.  Thought it might be
interesting to the hfsig too.  Did I miss any "good ones"?
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Subject:       High Speed HF modem progress
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X-mailer:     PMail v3.0 (R1a)
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Hi all,


I have put a posting out on Usenet for more on an "HF channel simulator" and 
have received some (not much though) feedback. There apparently are narrow 
band and wide band simulators, the latter being for spread spectrum (SS) 
applications and there are some interest presently by the military in this. 
We are mostly interested in a narrow-band simulator, that, by the way, can 
be a very complex thing if indeed you want to simulate the behavior at a 
particular location at aparticular instant in time. Those of you that have 
played with"IONCAP" and similar program will have some idea what this 
involves. There is also a much simpler simulation using the CCIR "good" and 
"poor" recommendations. These models allows one to adjust S/N settings and 
allows the modem to be evaluated in alittle as 0.1 dB steps. I have some 
scanty specs on the CCIR model can anyone help with obtaining a copy of 
this? (It is in the Dubrovnic plenary session, ca. 1989). 

Otherwise, I am in the process of bringing up a 100 baud QPSK single tone 
modem. It is possible that such an arrangement using two parallel channels 
will allow robust 400 bps using a regular RTTY channel bandwidth (without 
coding with Golay (24,12) the rate would be 200 bps). This code will run 
on the Cardinal soundcard. The CCIR channel simulator will also run on the 
Cardinal sound card.

Does anyone have any ideas on spread spectrum implementations for HF? 

I have not heard much from anyone being interested in participating in code 
development. You are missing out on some very interesting and educational 
opportunities. If I you are interested, let us hear from you. 

73's

Johan
KC7WW
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X-Mailer: ELM [version 2.4 PL23]
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Content-Length: 399       

Hi 

I realize this is not the current topic, but a list of BBSs which 
have ports on 2 or more frequencies would be of some value.  THe BBSSIG is
making a table of states/substate identifiers and a list of these
hf net interconnects would be of value.

Does someone have such a list? 
Could we build one for first hand information?

I am willing to compile this list if that will help.

73 Barry
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Message-Id: <Pine.SUN.3.90.941018095228.29382K-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Johan,

Forgive the delay in responding to your recent postings. They contain a 
lot of information and it's taken me some time to hoist in even part of 
it!

> 
> I have put a posting out on Usenet for more on an "HF channel simulator" and 
> have received some (not much though) feedback. There apparently are narrow 

I did a literature search on the University of Washington's online 
catalog and couldn't find a single reference to HF channel simulators. I 
haven't had a chance to manually search the IEEE index.

> allows the modem to be evaluated in alittle as 0.1 dB steps. I have some 
> scanty specs on the CCIR model can anyone help with obtaining a copy of 
> this? (It is in the Dubrovnic plenary session, ca. 1989). 

If you can send some more information I'll try the UoW engineering library.

>
> Otherwise, I am in the process of bringing up a 100 baud QPSK single tone 
> modem. It is possible that such an arrangement using two parallel channels 
> will allow robust 400 bps using a regular RTTY channel bandwidth (without 
> coding with Golay (24,12) the rate would be 200 bps). This code will run 
> on the Cardinal soundcard. The CCIR channel simulator will also run on the 
> Cardinal sound card.

The sound card seems like a good approach. TAPR's DSP-93 is pricey and 
has a long delivery time.

> 
> Does anyone have any ideas on spread spectrum implementations for HF? 
> 

I've done some work with narrow-band spread spectrum transmission of
digital video over wireline. (This was some years ago and so we were doing
everything in hardware. These days a run of the mill DSP could do the same
thing.) This approach may be applicable to HF but I have no experience 
with this application. One observation I could make is that the scheme we 
used seemed to be quite sensitive to the phase distortion of the channel. 
I suspect the phase distortion of the HF channel is going to present a 
challenge regardless of the modulation scheme we pick.

> I have not heard much from anyone being interested in participating in code 
> development. You are missing out on some very interesting and educational 
> opportunities. If I you are interested, let us hear from you. 

Please count me in! What's the first task you have in mind?

	Hugh
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X-Mailer: Microsoft Mail V3.0


Johan -- I'm interested in the HF channel simulator project. I've ordered a 
copy of CCIR Rec. 520-1, which I think includes specifications for CCIR 
standard channels. In Kantronics' May, 1994 QEX article about G-TOR, they 
refer to an HF channel simulator they used to test their G-TOR system. This 
simulator used a TMC320C30 and implemented the "good, moderate, poor and 
flutter fading channels prescribed by the CCIR as recommended for simulator 
test channels." That seems like a good place to start. I should have the 
document in a week or so and will report here on what I find out about the 
CCIR standards.

Then again, maybe I'm behind the power curve and the rest of you already 
know all about these CCIR recommended channels?

 -- Jon, KE3Z
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	(Smail3.1.28.1 #6) id m0qxIZY-000B9bC; Tue, 18 Oct 94 13:43 EDT
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From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
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Subject: RE: [HFSIG:17] HF Channel Simulator
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Encoding: 6 TEXT
X-Mailer: Microsoft Mail V3.0


Oh, I should also mention that the November QEX editorial is about the need 
for HF channel simulation and refers to this mailing list, with instructions 
on how to access it. Maybe that'll drag a few more people into the mix.

 -- Jon
From FORRERJ@frl.orst.edu Tue Oct 18 13:50:01 1994
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Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 18 Oct 1994 11:49:42 PST8PDT
Subject:       Re: [HFSIG:16] Re: High Speed HF modem progress
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <56A91835976@frl.orst.edu>

Hi Hugh,

I must apologize that we jumped into the deep end - if you are 
somewhat overwhelmed by the details, hang in there. 

The channel simulator would play an important and necessary role during 
evaluation. From re-reading Ken Wickwire's excellent QEX articles (ca. 
1992) and also from Freeman's handbook, I found that CCIR rep. 549-2 (XVI 
th Plenary Assembly, Dubnovrik, 1986, Vol III) contains a wealth on this 
topic. Likewise, have found that our library does not have these reports, 
so hopefully, someone else may be able to help out. I note that Jon may be 
able to help there - we will appreciate any efforts to locate this source 
of information.

It is obvious that a full-blown channel simulator is a very 
complex thing, perhaps a project that someone could pursue, however, a 
simpler model, that perhaps includes multipath with variable delay, 
fading rate, channel bandwidth and S/N, may suffice to get us on the right 
track. It would be really great if we could establish a few norms for the 
known modulation schemes under such conditions and then direct efforts into 
those that are most promising.  

Regarding the DSP platform - the TAPR DSP-93 is a fine design and in time 
will establish a good base of users and applications. Personally I have 
found the DSP sound card approach quite attractive for development work 
and have collected a number of useful tools along the way. I also 
am interested in the possibilities of integrating this hardware into the 
mainstream OS. You probably are aware that there are some very innovating 
DSP- related API components under development that will come on-line in the 
near future.

Presently I am working on DSP code subroutines that would be needed in 
just about all future demodulators - low distortion cosine and sine 
generators where carrier frequency and sample rate may be variable, i.e. 
for splitting a signal into its I/Q components, PLL's, Costa's loops etc. 
It becomes a relatively painless process to build demodulators - building 
good AGC, phase scynchronisers, bit clock extractors, however, still 
remains the challenge. This software uses, as a basis, the demo software for 
a sound card that accompanies an article that will feature in the November 
issue of QEX. I'll be happy to share the code with those experimenting with 
a Cardinal or Orchid sound card.  

>From your comments on SS, it appears that I need to do more homework on SS. 
It appears that once we get it to work, it may be the solution to many of 
our present problems. One question - does it mean that if we have found our 
efficient modulation scheme, that it is just a matter of implementing it 
on top of the SS coder/decoder? (pardon my ignorance).


73's

Johan
KC7WW













From Rick_Whiting@ATK.COM Tue Oct 18 15:52:30 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxLVL-0000WEC; Tue, 18 Oct 94 15:51 CDT
Received: from gateway1.ATK.COM by ATK.COM (5.65/1.34)
	id AA20157; Tue, 18 Oct 94 15:51:22 -0500
Message-Id: <9410182051.AA20157@ATK.COM>
Date: 18 Oct 1994 16:00:58 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: Re: HF Channel Simulation
To: "Post hfsig TAPR" <hfsig@tapr.org>

                       Subject:                               Time:3:30 PM
  OFFICE MEMO          RE>HF Channel Simulation               Date:10/18/94
I had our Engineering Library run a search of ITU/CCIR docs for HF channel
simulation.  Interestingly enough, they didn't hit on CCIR Radio Report 549-2
but they did come back with:

Recmn 520-1 Use of High Frequency Ionospheric Channel Simulators - Section
3Ac - Influence of the Ionosphere.

Recmn 520-2 (Same description as above).

Recmn 549-3 (Same description as above).

There were also references to other ITU/CCIR Reports on stuff like adaptive
automatic HF radio systems (551-2), multi-frequency-shift keying techniques
for HF (702), radiotelegraph circuits network architecture for HF data (995),
use of coding diversity on HF data circuits (1132), etc.  Looks like a wealth
of info.  The bad news is that none of these are in our library!

By the way, one of my contacts at Alliant Techsystems' Signal Analysis Center
in Annapolis suggested the accession citation of interest is CCIR Radio
Report 549-2, "HF Ionospheric Regulations, Channel Simulators, Volume III." 
CCIR 549-2 was also mentioned by other "posters" to TAPR/hfsig.

73/Rick W0TN



From FORRERJ@frl.orst.edu Wed Oct 19 11:14:41 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxdet-0000p4C; Wed, 19 Oct 94 11:14 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA00222 for <hfsig@tapr.org>; Wed, 19 Oct 1994 01:53:32 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 19 Oct 94 9:14:34 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 9:14:27 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 19 Oct 1994 09:14:20 PST8PDT
Subject:       Re: [HFSIG:20] Re: HF Channel Simulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <57FFB412162@frl.orst.edu>

Hi all,

Thanks for all the good work being done on the channel simulation. I have 
been promised some additional documentation and also found out a bit more 
on folks doing this kind of work for a living. Soon as I have more to work 
with, I'll share the details.

Jon's comment on looking at the QEX article on G-TOR reminded me that I 
spoke with Glenn Prescott at the last DCC. He is at the Univ. of Kansas and 
I guess that is where that 320C30-based simulator is located. Does anyone 
perhaps have Glenn's e-mail address? It may be worth dropping him a line.

Glad to hear from you too Walt - I'll prepare a posting on what I use for 
DSP development work for those that wish to consider purchasing the 
right sound card option.

Barry, have you gotten feedback yet on your posting on "2-port" HF 
capability?

Take care,

Johan
KC7WW
From g4guo@dircon.co.uk Wed Oct 19 15:32:04 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxhfz-0001BcC; Wed, 19 Oct 94 15:31 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA23850
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 19 Oct 1994 21:32:18 +0100
Received: by dircon.co.uk (5.67b) id AA23846; Wed, 19 Oct 1994 21:32:16 +0100
Date: Wed, 19 Oct 1994 21:32:15 +100 (BST)
From: Charles Brain <g4guo@dircon.co.uk>
Subject: H.F modems
To: hfsig@tapr.org
Message-Id: <Pine.3.89.9410192101.A23693-0100000@tdc.dircon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello,
 A good starting place for H.F modems is Proposed Federal Standard  1052.
 The main body of the standard describes a serial tone modem, Appendix A
 contains details of a parallel tone modem and Appendix B the Data Link 
 Protocol.
  Also anyone developing Mil-Std-188-141A/ FS1045/1046 can get a DOS/Windows 
 package to test it using a sound blaster card from ntia.its.bldrdoc.gov  in
 dist/ale-cd.
  My main concern is on what frequencies these modems will be used? They use
 voice bandwidths so the C.W/RTTY frequencies are probably out and if you go
 into the voice portions you will be accused of being a slow scan operator!
  I would like to see channel adaption discussed, why bother getting the last
 db of performance when a lot more can be gained by moving to a new channel!
  I would be more interested in very robust slow speed modems i.e chirp. The
 company I work for have developed a chirp modem but I believe it uses about
 5x56000 dsps. 
  Although I have ordered a DSP93 board I tend to think it really isn't 
 powerful enough for more advanced modems. 
  The 'in' thing appears to be parallel modems using soft decoding and 
 Trellises.

 Regards Charles



-----------------------------------------------------------
| 73 Charles H. Brain G4GUO                               |
| E-mail g4guo@dircon.co.uk                               |
| Tel Day (0245)353221 Xtn 3254                           |
|     Eve (0245)469382                                    |
| TCP/IP g4guo.ampr.org  AX25 g4guo@gb7esx                |
| Snail 2 Daisy Court, North Springfield, Chelmsford.     |
|       ESSEX. CM1 5QU. U.K                               |
|---------------------------------------------------------|

From barry@ia.net Wed Oct 19 15:51:51 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxhz7-0001N8C; Wed, 19 Oct 94 15:51 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id PAA09357 for hfsig@tapr.org; Wed, 19 Oct 1994 15:51:15 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410192051.PAA09357@allanon.ia.net>
Subject: found CCIR 549-2
To: hfsig@tapr.org
Date: Wed, 19 Oct 1994 15:51:14 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1327      

Hi all,
 
I just received a copy of CCIR Report 549-2.  It was faxed in here
and is readable, but would not survive another fax.  A paper copy is on
the way and should be here in a few days.
 
Quoting the Report
 
"This Report describes a Gaussian-scatter HF channel model for multiplicative
distortion, the expermiental method used to confirm the validity and the
bandwidth limitation of this model, and one implementation of an HF
simulator based on this model."
 
The entire Report is about 9 pages and contains 3 figures, 2 nasty looking
equations, 20 references, and 2 Annex(s) with 2 more figures.
 
Figure
1.  Power Spectra of the multipath components of a CW signal.
2.  Block diagram of HF ionispheric channel models.
3.  Tap-gain spectra in validated Gaussian-scatter model.
4.  Recording the channel characteristics.
5.  Simulation of the channel using recorded characteristics.
 
Johann, I'll mail you a copy of the Report when I get the real copy.
 
FREE COPIES!
Well sort of.  The first 5 people who request a copy will get one free.
Please be able to make some use of it!
 
Hope this helps,
 
Barry  wa0rjt
 
barry@ia.net                      I read this in the evenings.
sys_bjb%afds@hobbes.cca.rockwell.com        Stared at continuously 8-5
                                                Central time!
 
 
 

From FORRERJ@frl.orst.edu Wed Oct 19 16:36:51 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxigi-0000d4C; Wed, 19 Oct 94 16:36 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id HAA02506 for <hfsig@tapr.org>; Wed, 19 Oct 1994 07:15:47 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 19 Oct 94 14:36:51 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 14:36:30 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 19 Oct 1994 14:36:26 PST8PDT
Subject:       Re: [HFSIG:22] H.F modems
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <58559841185@frl.orst.edu>

Hello Charles,

Nice to hear from you. You certainly are bringing up a number of issues 
that have resulted in the formation of this HFSIG - good for you!

Let us entertain a few notions and bring everyone up to speed: The HF modems 
that Charles are mentioning are all in the family of standards built around 
MIL-STD-188. This includes a 39 parallel-tone, 16-parallel tone, and 8-ary 
FSK. The latter one is also known as the ALE format. NTIA makes a CD-ROM 
test source available, primarily for testing ALE equipment. Some of these 
modems are capable of 2400 bps (single channel or time-divison multiplexed) 
and are not shy about fully utilizing a 3kHz bandwidth channel. Several 
outfits are producing such modems, and they are quite pricey - at least out 
of reach for the usual radio amateur. In my opinion - (for what its worth) 
this is more or less brute force bandwidth & power to meet a specific 
objective. It is my belief that it is our challenge as radio amareurs to 
come up with something a bit more refined, superior in performance, and 
affordable. However, these documents makes a good source of information.

The chirp modulation modems that Charles mentions, implements a form of 
narrow-band SS. I have a couple of papers from the IEE on the theory and 
implementation details (let me know if you are interested in the 
references). If you have ever dealt with chirp and chirp-z transforms, you 
will have some idea what this is all about. This kind of innovation gives me 
hope that something as innovative will eventually lead to better solutions. 

You are quite correct about the modern trend toward parallel modems and 
clever coding, and we are heading that way too - though, hopefully, by 
doing our homework first to find out what basic modulation scheme to 
use - this is the whole idea behind the simulator. Hopefully we will have 
this basic knowledge shortly and then be able to move on to working on 
coding theory and eventually protocol. 

In an earlier posting I provided a guestimate of the capabilities 
of a few modulation schemes (some including coding) and shown that a 
typical single-DSP platform would perhaps (just a guess) be able to handle 
a x4 parallel situation (using fairly conventional modulation schemes). I 
hope that we would be able to do at least as good as the CLOVER II 
system. I am pleased to hear that you took the plunge with the DSP-93 - keep 
us posted on your developments.

Thanks for your input - keep them coming.

73's 

Johan
From FORRERJ@frl.orst.edu Wed Oct 19 16:39:21 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxij8-0001EuC; Wed, 19 Oct 94 16:39 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id HAA02514 for <hfsig@tapr.org>; Wed, 19 Oct 1994 07:18:17 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 19 Oct 94 14:39:20 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Oct 94 14:38:58 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 19 Oct 1994 14:38:55 PST8PDT
Subject:       Re: [HFSIG:23] found CCIR 549-2
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <585641372D4@frl.orst.edu>

Barry,

That is great news - looking forward seeing the document.

Johan
From barry@ia.net Wed Oct 19 18:05:51 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxk4n-0001I9C; Wed, 19 Oct 94 18:05 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id SAA10200 for hfsig@tapr.org; Wed, 19 Oct 1994 18:05:17 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410192305.SAA10200@allanon.ia.net>
Subject: Re: [HFSIG:25] Re: found CCIR 549-2
To: hfsig@tapr.org
Date: Wed, 19 Oct 1994 18:05:16 -0500 (CDT)
In-Reply-To: <585641372D4@frl.orst.edu> from "Johan Forrer                                                                             FL" at Oct 19, 94 04:42:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 606       


Johan

Sorry I missed on your name!

Send me a good address.

Do you know anyone that works for Rockwell in Dallas?  I got the
company librarian here in Cedar Rapids to make a few calls.  Seems 
like there might be other items of interest in the lib there, but
searching via long distance is not effective.  They are very good
at the library tasks but I hate to take up their time.  We get
regular ethics lectures...

I am also aware that the comm division does ALE and other hf 
"special" tasks.  They might be able to help but are usually reluctant
to go public with their knowledge.

73 Barry wa0rjt


From shane@mdd.comm.mot.com Wed Oct 19 18:37:29 1994
Return-Path: <shane@mdd.comm.mot.com>
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qxkZS-0001EAC; Wed, 19 Oct 94 18:37 CDT
Received: from pobox.mot.com ([129.188.137.100]) by ftpbox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA19818; Wed, 19 Oct 1994 18:37:21 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA17728; Wed, 19 Oct 1994 18:36:04 -0500
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA14097; Wed, 19 Oct 94 16:36:02 PDT
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA19268; Wed, 19 Oct 94 16:36:00 PDT
Date: Wed, 19 Oct 1994 16:36:00 -0700 (PDT)
From: Hugh Shane <shane@mdd.comm.mot.com>
X-Sender: shane@daffyduck
To: hfsig@tapr.org
Subject: Re: [HFSIG:19] Re: High Speed HF modem progress
In-Reply-To: <56A91835976@frl.orst.edu>
Message-Id: <Pine.SUN.3.90.941019161433.29382f-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Tue, 18 Oct 1994, Johan Forrer FL wrote:

> 
> our present problems. One question - does it mean that if we have found our 
> efficient modulation scheme, that it is just a matter of implementing it 
> on top of the SS coder/decoder? (pardon my ignorance).
> 

Our wireline digital video transmission system convolved the data with a 
pseudo-noise data stream, converted this to analog, and put the resulting 
audio signal on the wire. On the receiving end, a correlation detector was 
used to recover the data.

In an RF system the audio would simply be shifted to the desired RF 
spectrum using suppressed-carrier frequency-conversion techniques. It 
would be interesting to consider how one might do this up-conversion 
(and down conversion on the receiving end) digitally. In the HF bands 
we're talking about signals that some DSPs could handle.

Well, more food for thought anyway &:)

	Hugh
From shane@mdd.comm.mot.com Thu Oct 20 13:07:20 1994
Return-Path: <shane@mdd.comm.mot.com>
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qy1tT-0001SlC; Thu, 20 Oct 94 13:07 CDT
Received: from pobox.mot.com ([129.188.137.100]) by ftpbox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA24690; Thu, 20 Oct 1994 13:07:09 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA14906; Thu, 20 Oct 1994 11:01:43 -0500
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA17483; Thu, 20 Oct 94 09:01:40 PDT
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA02609; Thu, 20 Oct 94 09:01:39 PDT
Date: Thu, 20 Oct 1994 09:01:39 -0700 (PDT)
From: Hugh Shane <shane@mdd.comm.mot.com>
X-Sender: shane@daffyduck
To: hfsig@tapr.org
Subject: Re: [HFSIG:23] found CCIR 549-2
In-Reply-To: <199410192051.PAA09357@allanon.ia.net>
Message-Id: <Pine.SUN.3.90.941020085912.29382k-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Wed, 19 Oct 1994, Barry Buelow - WA0RJT wrote:

>  
> FREE COPIES!
> Well sort of.  The first 5 people who request a copy will get one free.
> Please be able to make some use of it!
>  

Dibs! And I'd be happy to reimburse you for copying and postage. Let me 
know how much. I'm hoping to be of assistance in designing and coding the 
channel simulator.

Hugh Shane
N7UAX
2915 NE 52nd St #402
Seattle, WA 98105
From wdubose@sacdm01.kelly.af.mil  Thu Oct 20 13:09:24 1994
Return-Path: <wdubose@sacdm01.kelly.af.mil>
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qy1v9-0001SlC; Thu, 20 Oct 94 13:08 CDT
Received:  by sacdm01.kelly.af.mil (5.65b/1.0.2-rct)
	id AA16818; Thu, 20 Oct 94 13:00:40 -0500
Message-Id: <9410201800.AA16818@sacdm01.kelly.af.mil>
Date: Thu, 20 Oct 94 13:00:25 -0500
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT)
Subject: Introduction
To: hfsig@tapr.org

Greetings All,

Let me introduce myself to the "net".

I am presently employed by the USAF at Kelly AFB, San Antonio Air
Logistics Center as Systems Manager for the Central Contracting
Contract Data Management Host (spell that office automation).  I
retired from the AF Reserve in 1993 after 26 years in the reserve
program.  For the last 14 years in the program, I was Chief of
Communications Maintenance for the 32nd Aeromedical Evacuation Group
and senior communicator in the Aeromedical Evacuation System.

During Desert Shield/Storm, I was Chief of Communications for the
Theater Aeromedical Evacuation System and stationed in Saudi Arabia.
The Aeromedical Evacuation System used HF communications exclusively
for command and control communications.

The year before Operation Just Cause, the "liberation" of Panama, the
AF held an exercise which included having a NCS at Kelly AFB and an
operational location in Panama.  This, as we were to learn, a good
practice for Operation Just Cause.  During Just Cause, we learned that
the 300 baud (Bell 102 Modem) communications we were using would *not*
hack the communications needs for Aeromedical Evacuation (AE).  We had
begun using a 300 baud communications device/terminal almost 3 years
before and it had connectivity problems from the first;  however, it
was so much better than voice (un-encrypted) communications that we
put up with the downside.

Because we fell flat with AE communications during Just Cause, our
Major Command arranged a test of high speed data capability using
Harris Corp, HF Comm Division's MIL-STD-188-110c modems and a NSA
blackbox that used the MIL-STD 39 parallel tone modem in the winter of
'90 at Scott AFB.  During the test we were able to pass 40K files over
HF at 2400 and 4800 BPS with no trouble except for *BIG* QSBs, QRN and
QRM.  We would lose chunks for the file but what we received was 100%
correct.  No ARQ was used...just straight RATT (ASCII) with ProCom as
the terminal program.

The Major Command (MAJCOM) Chief Surgeon and MAJCOM AE Commander and
my unit commander directed me to include a similar demonstration/test
during AE's summer 90 exercise at Ft Hunter-Liggett, CA.  I arranged
for Harris and SAIC/SAIT to bring equipment (the MIL-STD modems and
TEMPEST LapTop computers) to demonstrate high speed HF data
transmission.  We were networked the Navy Hospital Ship on the west
Coast, Army and Air Force Medical Units and AE units on HF and
compare the capability of our old equipment (300 baud, Bell 102) with
the new modems running TCP/IP.

SAIC/SAIT forgot that their software TCP/IP (probably KA9Q NOS) would
be required to key the transmitter.  Thus, we could only duplicate
the previous demonstration but did confirm that 2400 and 4800 BPS
data transmissions on HF were possible.  90 days after the exercise
concluded, I was in Saudi.

While in Saudi, we had the opportunity to use Harris ALE and
MIL-STD-188-110c modems.  The ALE was *NOT* suitable for our network
operations (that's another story) and because our AE nets were much
like NTS nets, I doubt that ALE will ever work on the hambands.

HF high speed data transmissions did work and work very well.  The
robustness of these modems running at 2400 BPS at 100 watts provided
better thruput than our 300 baud equipment running 1000 watts.  Some
units found that the MIL-STD modems on 100 watt transceivers worked
better that 100/300 baud RATT (ASCII) at 20 KW.

As one of the evaluators of Harris' AN/URC-119 (commercially known as
the RF-350 series) HF equipment prior to production and having keep
up my relationship with Harris technical personnel, I was privy to
the technical information on their MIL-STD-188-110c modems.  I also
had the opportunity to evaluate Rockwell-Collins HF equipment that
was similar to the Harris AN/URC-119 system.  The MIL-STD, high
speed, robust modems use external DSP technology in their modems to
achieve the modem/transmission protocol.

Almost a year ago, Lou, N5SGL, discovered some of Johan's (KC7WW)
work and he and I began exchanging E-Mail about robust high speed HF
modems using commercial-off-the-shelf (COTS) sound boards.  During my
many messages with Johan, I have come to believe that hams (those of
you with a much high level of technical competency than I) can
reproduce the MIL-STD modem/transmission protocols using a DSP/ASP DMA
soundcard.

One major question must be answered.  Do we (hams) want to simply
duplicate these proven MIL-STD modems (that cost a bundle) or roll
our own along the same line.  The MIL-STD modems BW will (just) fit
into a SSB bandpass...but do we want something that wide?  The will
run 4800 BPS w/o the Reed-Solomon (RS) coding and 2400 with RS coding.
How many BPS can we get using a 8 tone (narrow spaced tones), modem
running 100 baud and can we keep the BW down to something that hams
in general and the FCC will "buy"?  Also, the cost of the "system"
must be affordable.  Should we use Golay or RS encoding for the FEC?
Many questions to be answered.

I believe we can obtain 1200 BPS with FEC and ARQ/CRC and 2400 BSP
w/o FEC but with ARQ/CRC in a *ROBUST* modem protocol.  I truly would
like to see a TCP/IP HF WAN (SMTP only) to augment and eventually
replace the HF NTS nets.

73,

Walt/K5YFW

Snail-Mail      Walt DuBose
                10909 Meadowhome
                San Antonio, Texas 78230

MABELL          HP 210-696-3196
                BP 210-925-6081

VHF-FM*         146.46 (w/CTCSS 146.2) / 147.06 (w/CTCSS 203.5)

UHF-FM*         446.0  (w/CTCSS 146.2)

HF SSB Mobile   7.213 LSB

HF CW (40/20)   U_CALL_IT

E-Mail k5yfw@sat.ampr.org (goes to k5yfw@k5yfw.ampr.org & k5yfw@sacdm10)
        (ham stuff...un-official...but important)

E-Mail k5yfw@sacdm10.kelly.af.mil
        (semi-official...all mailgroups including hfsig)

E-Mail wdubose@sacdm01.kelly.af.mil
        (official U.S. Government stuff and emergency communications)

* Just in case you come San Antonio.
From barry@ia.net Thu Oct 20 20:48:01 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qy95K-0001dEC; Thu, 20 Oct 94 20:47 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id UAA19886 for hfsig@tapr.org; Thu, 20 Oct 1994 20:47:39 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410210147.UAA19886@allanon.ia.net>
Subject: Re: [HFSIG:28] Re: found CCIR 549-2
To: hfsig@tapr.org
Date: Thu, 20 Oct 1994 20:47:38 -0500 (CDT)
In-Reply-To: <Pine.SUN.3.90.941020085912.29382k-100000@daffyduck> from "Hugh Shane" at Oct 20, 94 01:14:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 494       

Hey - you made the cut!

73 Barry

> 
> 
> 
> On Wed, 19 Oct 1994, Barry Buelow - WA0RJT wrote:
> 
> >  
> > FREE COPIES!
> > Well sort of.  The first 5 people who request a copy will get one free.
> > Please be able to make some use of it!
> >  
> 
> Dibs! And I'd be happy to reimburse you for copying and postage. Let me 
> know how much. I'm hoping to be of assistance in designing and coding the 
> channel simulator.
> 
> Hugh Shane
> N7UAX
> 2915 NE 52nd St #402
> Seattle, WA 98105
> 

From g4guo@dircon.co.uk Sat Oct 22 05:19:26 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qydXo-00005ZC; Sat, 22 Oct 94 05:19 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA01823
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 11:20:02 +0100
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA01808; Sat, 22 Oct 1994 11:19:50 +0100
Date: Sat, 22 Oct 1994 11:19:50 +0100
Message-Id: <199410221019.AA01808@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: Z8530 and WB6YMH mod

Charles Brain <g4guo@dircon.co.uk> writes:
> Hello Folks,
>  I am desperatly trying to obtain details os WB6YMH's 'trick' that allows 
> a Z8530 SCC chip to act as a dumb serial/parallel converter. I am trying 
> to take a serial synchronous bit stream from a modem and process it 
> inside a P.C. !HELP!
> 
> Regards Charles Brain G4GUO 
> 
> -- 
> -----------------------------------------------------------
> | 73 Charles H. Brain G4GUO                               |
> | E-mail g4guo@dircon.co.uk                               |
> | Tel Day (0245)353221 Xtn 3254                           |
> |     Eve (0245)469382                                    |
> | TCP/IP g4guo.ampr.org  AX25 g4guo@gb7esx                |
> | Snail 2 Daisy Court, North Springfield, Chelmsford.     |
> |       ESSEX. CM1 5QU. U.K                               |
> |---------------------------------------------------------|
> 
From g4guo@dircon.co.uk Sat Oct 22 05:19:36 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qydXx-00005ZC; Sat, 22 Oct 94 05:19 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA01839
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 11:20:14 +0100
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA01817; Sat, 22 Oct 1994 11:19:57 +0100
Date: Sat, 22 Oct 1994 11:19:57 +0100
Message-Id: <199410221019.AA01817@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:29] Introduction

Hello Walter

> While in Saudi, we had the opportunity to use Harris ALE and
> MIL-STD-188-110c modems.  The ALE was *NOT* suitable for our network
> operations (that's another story) and because our AE nets were much
> like NTS nets, I doubt that ALE will ever work on the hambands.
> 

I would be really interested to know why you feel the ALE was unsuitable
for this type of operation. Overhere in Europe we have our doubts as well
but these are to do with the much higher levels of interference especially
during daylight hours.
 Also are you talking about MIL_STD-188-141A or Harris's fast ALE system which
is being developed as part of AHFDS (Advanced HF Data System).
 I believe that some form of narrower band ALE and RTCE is needed to try to spread
activity away from 20 meters and towards the WARC/higher bands. 
 I operate Clover from this QTH and so far have only worked stations on 20 meters
even during times when the higher bands have been open. Our H.F bands are a wonderful
resource that we are hardly even beging to use. I ask you AX25 on 20 meters! 
(Oophs sorry no protocol wars!!!).

Regards Charles.
From g4guo@dircon.co.uk Sat Oct 22 06:34:26 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyeiJ-0000PuC; Sat, 22 Oct 94 06:34 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA05615
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 12:34:32 +0100
Received: by dircon.co.uk (5.67b) id AA05611; Sat, 22 Oct 1994 12:34:30 +0100
Date: Sat, 22 Oct 1994 12:34:29 +100 (BST)
From: Charles Brain <g4guo@dircon.co.uk>
Subject: Re: [HFSIG:32] Re: Introduction
To: hfsig@tapr.org
In-Reply-To: <199410221019.AA01817@dircon.co.uk>
Message-Id: <Pine.3.89.9410221244.A5544-0100000@tdc.dircon.co.uk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sorry I meant night time and begining!

-----------------------------------------------------------
| 73 Charles H. Brain G4GUO                               |
| E-mail g4guo@dircon.co.uk                               |
| Tel Day (0245)353221 Xtn 3254                           |
|     Eve (0245)469382                                    |
| TCP/IP g4guo.ampr.org  AX25 g4guo@gb7esx                |
| Snail 2 Daisy Court, North Springfield, Chelmsford.     |
|       ESSEX. CM1 5QU. U.K                               |
|---------------------------------------------------------|

From k5yfw@k5yfw.ampr.org  Sat Oct 22 09:22:30 1994
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyhKy-0001rqC; Sat, 22 Oct 94 09:22 CDT
Date: Sat, 22 Oct 94 08:42:56 CST
Message-Id: <2111@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: Re: [HFSIG:32] Re: Introduction
In-Reply-To: Your message of Sat, 22 Oct 94 05:28 CDT
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Greetings Charles and All,

In Charles message <199410221019.AA01817@dircon.co.uk> he writes:
> Hello Walter
> 
> > While in Saudi, we had the opportunity to use Harris ALE and
> > MIL-STD-188-110c modems.  The ALE was *NOT* suitable for our network
> > operations (that's another story) and because our AE nets were much
> > like NTS nets, I doubt that ALE will ever work on the hambands.
> > 
> 
> I would be really interested to know why you feel the ALE was unsuitable
> for this type of operation. Overhere in Europe we have our doubts as well
> but these are to do with the much higher levels of interference especially
> during daylight hours.
>  Also are you talking about MIL_STD-188-141A or Harris's fast ALE system which
> is being developed as part of AHFDS (Advanced HF Data System).
>  I believe that some form of narrower band ALE and RTCE is needed to try to spread
> activity away from 20 meters and towards the WARC/higher bands. 
>  I operate Clover from this QTH and so far have only worked stations on 20 meters
> even during times when the higher bands have been open. Our H.F bands are a wonderful
> resource that we are hardly even beging to use. I ask you AX25 on 20 meters!
> (Oophs sorry no protocol wars!!!).
> 
> Regards Charles.

        You have the correct MIL-STD referenced for the ALE we used.

        The Areomedical Evacuation (AE) net is much like a traffic net here
        in the U.S. (Please note I didn't say colonies Charles as I got
        a personal flame from a super patriot last time I used it...Hi Hi)
        We had up to 30 or so stations checked into the net on voice and
        when they need to pass traffic, they called the net station, got
        permission to call another station and then passed their traffic
        using a Bell 103, 300 baud, terminal device.  This was the
        normal pre-ALE method.

        When we got ALEs on all our Harris HF radios, then the individual
        station would simply initiate an automatic connect with the station
        he wished to talk to and when voice contact was established, they
        would carry on in voice or with their terminal devices.  Since
        there is muting on the audio in monitor mode and the ALE is scanning
        the 3 or 4 frequencies we were assigned, if another station needed
        to talk to another station, they pushed the connect button and the
        ALE went to the channel it had memorized as the place where the
        called station should be or started calling on each of the assigned/
        programmed channels.  If on any of those channels there was a
        voice or data QSO going on, it would place its signaling tone on
        the frequency it did not recognize it and "stepped" on the QSO.
        If critical AE data was being passed, it had to be
        re-transmitted.  It really had a way of ruining a QSO as the
        signaling took many seconds of transmission time on each
        frequency to establish a connection.

        I am afraid that on crowed hambands, unless we have specific
        frequencies set aside for ALE signalling, we will incur the
        wrath of many hams.  Also, this is compounded by the hidden
        transmitter effect...even if ALEs were made smart enough to
        listen for signals and not transmit on channels/frequencies
        where a QSO existed...it might be able to hear only one side of
        a QSO thus stepping on the QSO.

        I hope I have explained the simply and adequately enough from an
        operational stand point rather than any technical standpoint.

        On another note, I notice that you say "Our H.F bands are a wonderful
        resource that we are hardly even beging to use."  I did notice on
        several of my trips to Europe and while in Saudi that the HF
        bands there have *much* less activity than on this side of the
        pond.

        Reference AX.25 on 20 meters.  Other than the lack of a good
        modem...and Johan, KC7WW and give you information on how to
        build a very good Bell 102 format modem to use on AX.25.
        However, you must remember that you cannot realiable receive
        data at over 100 or so baud on HF due to the ever present
        mulit-path signals...this should be covered in some of HALs
        writings.  I have summerized some of these and am willing to
        place them here on the SIG if there is interest.

        Try going to 110 baud on AX.25 on 20 meters and see if you don't
        find the thruput much better.  Also, run just one connected
        session on a frequency or limit it to *no more* than two connected
        sessions on a frequency.  You may find the thuput comparible to
        100 baud RTTY/ASCII with no errors.

        73,  Walt-k5yfw@home.today

        PS, Charles, notice I used the "American" spelling of meters...
        Hi Hi.  -- k5yfw
From g4guo@dircon.co.uk Sat Oct 22 11:59:38 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyjn3-00004QC; Sat, 22 Oct 94 11:59 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA04109
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 22 Oct 1994 17:57:36 +0100
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA04088; Sat, 22 Oct 1994 17:57:33 +0100
Date: Sat, 22 Oct 1994 17:57:33 +0100
Message-Id: <199410221657.AA04088@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:34] Re: ALE

k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) writes:
> Greetings Charles and All,
 
          If on any of those channels there was a
>         voice or data QSO going on, it would place its signaling tone on
>         the frequency it did not recognize it and "stepped" on the QSO.
>         If critical AE data was being passed, it had to be
>         re-transmitted.  It really had a way of ruining a QSO as the
>         signaling took many seconds of transmission time on each
>         frequency to establish a connection.

Hi Walter,
 O.K I understand about the problem, The fredricks ALE controller has
a voice detect function, however as they are only using a TMS320C10 
I guess it is not very effective. As you say this is a problem. I have
seen an intelligent squelch that uses a DSP in conjunction with a neural
net to recognise speech on a channel, it takes a few hours to train though.
Possibly some form of pilot tone SSB would be more suitable. Or the ALE 
could send a "Is the channel free call" I guess there are a lot of diffent
things that could be done.

 As far as Chelmsford is concerned no I am not a member although I have
been to the club a couple of times and I am friendly with one of the
committe members. I will pass on your greetings.
By the way I work at Mr Guglielmo's Wireless Works in Chelmsford.

 As far as packet is concerned I wonder if it would be possible to
use a DSP based channel conditioner using the HDLC flags as a training
sequence to reduce the multi-path problems. Also if a data frame has to be
sent many times it may be possible to store multiple copies of the frame and
do a majority vote on the data. It should be possible to do this without
a change in the protocol. There is probably some flaw in my idea.

I do think an improved packet protocol for HF is needed, I know a lot of people
are thinking about the problem. I would favour a waveform similar to CLOVER
i.e using a small number of tones to reduce baud rate and a priority ack protocol.

As far as the English is concerned, my computer speaks Colonial English, anyway
my father came from the Canadian Colony so I can just about understand you lot!!

Regards Charles.
From n7oo@huachuca-emh8.army.mil Sat Oct 22 18:08:37 1994
Return-Path: <n7oo@huachuca-emh8.army.mil>
Received: from huachuca-emh8.army.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qypYA-0000v0C; Sat, 22 Oct 94 18:08 CDT
Message-Id: <m0qypYA-0000v0C@dptspd.sat.datapoint.com>
Date:     Sat, 22 Oct 94 16:03:23 MST
From:     Jack Taylor <n7oo@huachuca-emh8.army.mil>
To:       hfsig@tapr.org
Subject:  Re:  [HFSIG:35] Re: ALE

Charles Brain suggests some changes could be made to ax.25 to make it more
effective for HF operations.

Be advised a revision to the ax.25 standard is "in the works" and is
currently before the ARRL futures committee for review.  If anyone is
interested in looking over the proposed new ax.25 standard it is available
via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt.  If after
review, comments wish to be made, they can be sent to one of the principle
authors, bbeech@huachuca-emh8.army.mil.

73 de Jack
From gjones@tenet.edu Sat Oct 22 19:09:35 1994
Return-Path: <gjones@tenet.edu>

Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyqVA-0001EuC; Sat, 22 Oct 94 19:09 CDT
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id TAA23199 for hfsig@tapr.org; Sat, 22 Oct 1994 19:09:30 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199410230009.TAA23199@Kay-Abernathy.tenet.edu>
Subject: Re: [HFSIG:36]  Re: ALE
To: hfsig@tapr.org
Date: Sat, 22 Oct 1994 19:09:29 -0500 (CDT)
In-Reply-To: <m0qypYA-0000v0C@dptspd.sat.datapoint.com> from "Jack Taylor" at Oct 22, 94 06:11:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 726       

Also - the published doc, with the changes the committee requested should be
avalible from the ARRL by request the first of the year.

Cheers - greg

According to Jack Taylor:
> 
> Charles Brain suggests some changes could be made to ax.25 to make it more
> effective for HF operations.
> 
> Be advised a revision to the ax.25 standard is "in the works" and is
> currently before the ARRL futures committee for review.  If anyone is
> interested in looking over the proposed new ax.25 standard it is available
> via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt.  If after
> review, comments wish to be made, they can be sent to one of the principle
> authors, bbeech@huachuca-emh8.army.mil.
> 
> 73 de Jack
> 

From rmackay@bud.peinet.pe.ca Sat Oct 22 20:35:35 1994
Return-Path: <rmackay@peinet.pe.ca>
Received: from bud.peinet.pe.ca by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyrqO-0000v5C; Sat, 22 Oct 94 20:35 CDT
Received: by bud.peinet.pe.ca; id AA12970; Sat, 22 Oct 1994 22:35:27 -0300
Date: Sat, 22 Oct 1994 22:35:26 -0300 (ADT)
From: Ron Mackay <rmackay@bud.peinet.pe.ca>
Subject: Re: [HFSIG:36] Re: ALE
To: hfsig@tapr.org
In-Reply-To: <m0qypYA-0000v0C@dptspd.sat.datapoint.com>
Message-Id: <Pine.3.89.9410222257.A12779-0100000@bud.peinet.pe.ca>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 22 Oct 1994, Jack Taylor wrote:

> Charles Brain suggests some changes could be made to ax.25 to make it more
> effective for HF operations.
> 
> Be advised a revision to the ax.25 standard is "in the works" and is
> currently before the ARRL futures committee for review.  If anyone is
> interested in looking over the proposed new ax.25 standard it is available
> via anonymous ftp from hereford.ampr.org /pub/hamradio/lapa.txt.  If after
> review, comments wish to be made, they can be sent to one of the principle
> authors, bbeech@huachuca-emh8.army.mil.
> 
> 73 de Jack
> 
Tried to get that file but "permission denied" instead for anonymous
log-in at least.

73 - Ron VE1AIC

From barry@ia.net Sat Oct 22 20:55:07 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qys9G-0000aMC; Sat, 22 Oct 94 20:55 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id UAA07692 for hfsig@tapr.org; Sat, 22 Oct 1994 20:54:40 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410230154.UAA07692@allanon.ia.net>
Subject: ASYNC vs Coherent
To: hfsig@tapr.org
Date: Sat, 22 Oct 1994 20:54:39 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 809       

I note that some of the comments on ALE refer to async.

This thought hasn't been a part of the discussions yet but I thought
it would be interesting before we all run off in one direction.

I'm not directly involved with the design of GPS rcvrs, but they 
are getting _really_ small, low power and, most important, CHEAP.
Street prices today are still a few hundred $.  You can buy reasonable
quantities of multi-channel units for in the range of $300 if you
know where to look.

This all leads to rather good frequency standards being possible in
the not too distand future.  Now being is phase lock is a little 
different issue, but real good frequency and timing are a start
in the right direction.  Knowing where and when to look for a signal
is much different than just free running.

73 Barry
wa0rjt


From g4guo@dircon.co.uk Sun Oct 23 02:54:16 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyxkr-0001UfC; Sun, 23 Oct 94 02:54 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA11966
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 23 Oct 1994 08:52:24 +0100
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA11958; Sun, 23 Oct 1994 08:52:22 +0100
Date: Sun, 23 Oct 1994 08:52:22 +0100
Message-Id: <199410230752.AA11958@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:38] Re: LAPA

Ron Mackay <rmackay@bud.peinet.pe.ca> writes:
> On Sat, 22 Oct 1994, Jack Taylor wrote:
> 
> Tried to get that file but "permission denied" instead for anonymous
> log-in at least.
> 
> 73 - Ron VE1AIC
> 
> 
> 

Hi Ron and all,

 Yes I got the same thing!

Regards Charles
From g4guo@dircon.co.uk Sun Oct 23 02:54:23 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qyxkz-0001UfC; Sun, 23 Oct 94 02:54 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA11960
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 23 Oct 1994 08:52:23 +0100
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA11954; Sun, 23 Oct 1994 08:52:17 +0100
Date: Sun, 23 Oct 1994 08:52:17 +0100
Message-Id: <199410230752.AA11954@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:39] ASYNC vs Coherent

Barry Buelow - WA0RJT <barry@ia.net> writes:
> I note that some of the comments on ALE refer to async.
> 
> This thought hasn't been a part of the discussions yet but I thought
> it would be interesting before we all run off in one direction.
> 

Hello Barry,

 Certainly a synchronous system should reduce calling time on air. A small
on air pool of calling frequencies could be used then after contact has been
made a QSY to another frequency could be initiated to prevent blocking of the
calling channels.
 Non synchronous "ALE" stations could call asynchronously.

 As we are not a military system we can rely on external time sources, in the
UK we have a transmission on 60 KHz called MSF this is an atomic time standard
you can buy a kit of parts to build a receiver for about $20. I guess WWV could
be used in the U.S. While we wait for GPS to drop in price.

 The next problem is to channelise the HAM bands to allow easier handling in the
database.

 Another big problem is the Radios themselves, when your rig reads say 14.070Mhz
what frequency is it actually on.  On SSB the dial frequency should be the
frequency of the suppressed carrier. The other modes well I dont know. 
 Also it would be nice to disable the input filtering or have solid state switching
of the filters as when my TS850 scans I hear the relays clicking (and wearing out).

 Frequency stability is becoming a big issue especially on modes like CLOVER 
where you have to be within 10 or so Hz of the correct frequency and stay there.

It would be nice if all modern radios had an external frequency reference input.

 Timeslots for sounding of stations would have to be arranged so as not to cause 
collisions.

 The modulation scheme during calling would need to be optimised for :
 1) Fast recognition.
 2) Robustness
 3) Easy to measure S/N, BER, MP etc.
 4) Measurement of path delay (this could be used to generate simple ionograms)

 A spin off of this of course would be a wonderful beacon system.

 All of this is perfectly possible with modern technology but I sometimes wonder
if the guys using 5 watts and a hand key don't have the right idea.
 ALE systems are being developed to reduce the skills required of the operator
and turn him into a simple communicator, operating is much of the fun of HAM radio.

Bring back spark!

Regards Charles
From KY1TLuck@aol.com Sun Oct 23 09:46:37 1994
Return-Path: <KY1TLuck@aol.com>
Received: from mail02.prod.aol.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qz4Bu-0000WFC; Sun, 23 Oct 94 09:46 CDT
Received: by mail02.prod.aol.net
	(1.38.193.5/16.2) id AA24759; Sun, 23 Oct 1994 10:46:29 -0400
Date: Sun, 23 Oct 1994 10:46:29 -0400
From: KY1TLuck@aol.com
Sender: KY1TLuck@aol.com
Message-Id: <941023104625991923@aol.com>
To: hfsig@tapr.org
Subject: Official Observers

I, for one, appreciate Greg's efforts at getting appropriate and detailed
info regarding this particular  OO/FCC matter out into the hands of those
subscribed to this list.  And I'm glad to see that ARRL HQ's Regulatory
Information Branch continues to be so promptly responsive.  This is good...

I might be able to shed some light on a couple of other aspects of this
matter, since it was I who was in charge of the ARRL/FCC Amateur Auxiliary
(Official Observer) program for much of my 7 years at ARRL HQ.  And having
been an Official Observer Coordinator in the ARRL's volunteer Field
Organization in two different ARRL Sections (Virginia and Eastern
Massachusetts), I have an unusual perspective from both sides of the fence.
 I can understand, for example, why Fred Sober would be writing to FCC.  And
I can understand -- from the administrative side -- why that's a bad move on
Fred's part.

For one thing, it's absolutely forbidden.  I know of no less than four
Official Observers and two Official Observer Coordinators who were "removed"
from their positions because of doing just that.  The ARRL gets real jumpy
when one of their troops makes contact with FCC, and this instance we're
discussing right now is absolutely a PERFECT example of why that's so.  
Yah, I know; we all -- most of us anyway -- tend to think that word from
Johnny Johnston is somehow that of God himself, FCC-wise.  But there's two
things to consider carefully:

1.  Johnny doesn't work for the enforcement part of FCC. In other words,
while he may (and often does) express his opinion about certain Part 97
regulations, they're just that, opinions.  They're not binding.  Only Part 97
itself is.  And let's get back to Part 97 in just a sec.

2.  I've personally witnessed the results of a VERY large number of inquiries
from amateurs to FCC in the past decade.  And I can assure you that,
depending on who is telephoned, faxed, written to, pestered at a hamfest, or
otherwise communicated with, the resulting opinions from FCC staff can -- and
usually are -- remarkably different.  This is clearly because of the way the
question is posed, and it stands to reason that since we amateurs are
typically very bad at communicating (sigh...) we're GOING to get differing
opinions.  

I'm getting painfully wordy, so let me sum up.

The whole issue is moot.  Greg has already correctly put things in
perspective; a packet bulletin is NOT, by ANY stretch of the imagination a
one-way transmission.  Transmissions from one TNC to another are two-way
transmissions.  Not one-way.  Period.  Thus, the supposed Notices of Apparent
Liability that Fred Sober speaks of will  never occur.  And if OO notices
happen, that's perfectly fine since they don't have the weight of Part 97
enforcement anyway, except by way of friendly amateur-to-amateur peer
pressure.  

I'd hate to guess how many whining phone calls I got every day for seven
years from amateurs who'd gotten "picked on" by OO notices.  My usual retort
to them was "gee, have you considered throwing the post card in the trash and
getting on with your amateur radio activities, OM?"  "Well, (sputter, fume),
but what are you gonna DO about this jerk who sent me the card, huh?"  "well,
I might drop him a note, congratulating him for continuing to express his
opinions on what he believes would make the bands a better place  to hang
out".  Which usually resulted in more sputtering and fuming, aimed at ME this
time, which was probably better than having it aimed at the volunteer who was
taking his best --  even if sometimes misguided  -- shot.

And, finally, let's all try to remember that this is a non-issue.  NALs won't
happen, and OO notices don't count, so let's move on.

73

------------------------------------------------------
     Luck Hurder, KY1T     **  KY1TLUCK@AOL.COM  **  
   Supporter of AMSAT, TAPR, and NARA 
-------------------------------------------------------



From n7oo@huachuca-emh8.army.mil Sun Oct 23 11:08:15 1994
Return-Path: <n7oo@huachuca-emh8.army.mil>
Received: from huachuca-emh8.army.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qz5St-0000d8C; Sun, 23 Oct 94 11:08 CDT
Message-Id: <m0qz5St-0000d8C@dptspd.sat.datapoint.com>
Date:     Sun, 23 Oct 94 8:57:40 MST
From:     Jack Taylor <n7oo@huachuca-emh8.army.mil>
To:       hfsig@tapr.org
Subject:  Re:  [HFSIG:40] Re: LAPA

I'd forgotten that the lapa.txt file on hereford.ampr.org was a "working
copy" of the proposed revised standard for ax.25 and not available for
anonymous ftp.  In view of Greg's comment that the ARRL will be releasing
the document (presumably for comment) in the near future, probably best
to wait for that one.  That way will avoid confusion as everyone will be
singing "from the same songbook".
73 de Jack
From barry@ia.net Sun Oct 23 12:46:24 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qz6ye-0000HkC; Sun, 23 Oct 94 12:45 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id MAA13394 for hfsig@tapr.org; Sun, 23 Oct 1994 12:10:07 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410231710.MAA13394@allanon.ia.net>
Subject: Re: [HFSIG:42] Official Observers
To: hfsig@tapr.org
Date: Sun, 23 Oct 1994 12:10:07 -0500 (CDT)
In-Reply-To: <941023104625991923@aol.com> from "KY1TLuck@aol.com" at Oct 23, 94 09:48:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1169      

Luck,

I appreciate your comments on the OO and FCC.  It is good to have
someone with first hand experience comment.

As you may recall, I threatened to petition the FCC on exactly
this issue a few months ago.  At the DCC in Mpls, I attempted
to defend my position that bltns are one-way and therefore
restricted to info bltns.

The attitude of the sysops in the crowd was:

1. ignorance of the rules - I expected better, but wasn't totally
surprised.

2.  why bother - no one seems to see that there are NO values and
any topic is acceptable for aa bltn.

Obviously I was disappointed at being laughed off the stage.  One
major technical contributor to packet said "let the channels get jammed, 
then there will be a reason to go faster".  

The major problem I have with this entire episode is that it is one 
more reason that people with real brains will leave ham radio.  The
idiots are overrunning us and the liberals are letting them.

It is very difficult to keep from screaming "dumb shit" into the 
microphone.

If this is an indication of where ham radio is going, I'll go 
back to my model trains.

73and thanks again for valuable insights,

Barry wa0rjt



From gjones@tenet.edu Sun Oct 23 15:34:52 1994
Return-Path: <gjones@tenet.edu>
Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qz9cw-0000qdC; Sun, 23 Oct 94 15:34 CDT
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id PAA16608 for hfsig@tapr.org; Sun, 23 Oct 1994 15:34:47 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199410232034.PAA16608@Kay-Abernathy.tenet.edu>
Subject: BBS Issue
To: hfsig@tapr.org
Date: Sun, 23 Oct 1994 15:34:47 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 425       

Hi Folks - would suggest we move the issue regarding the OO message
concerning packet BBS messages be moved over to the BBSSIG mailing list, and
let the HFSIG continue messages on the current topic.(i.e. simulators and
more).  

By the way Johan - I think we can all agree that the current content of the
HFSIG has been just great!  Good Job.  I really look forward to what the
group will eventually produce.

Cheers - Greg

From barry@ia.net Sun Oct 23 21:35:05 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzFFV-0001UIC; Sun, 23 Oct 94 21:35 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id VAA02872 for hfsig@tapr.org; Sun, 23 Oct 1994 21:34:54 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410240234.VAA02872@allanon.ia.net>
Subject: sorry - wrong SIG
To: hfsig@tapr.org
Date: Sun, 23 Oct 1994 21:34:54 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 107       

Sorry group,
I must have replied to the wrong msg from Luck.  I'll try to be more
careful.

Barry wa0rjt


From muphaus@cris.com  Mon Oct 24 00:41:38 1994
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzIA2-0001N6C; Mon, 24 Oct 94 00:41 CDT
Received: from starcore.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by starcore.cris.com (4.1/SMI-4.1)
	id AA06646; Mon, 24 Oct 94 01:41:21 EDT
To: hfsig@tapr.org
From: muphaus@cris.com (Marv Uphaus)
Subject: HFSIG on the Internet...
Date: Sun, 23 Oct 1994 13:13:02 -0500
Organization: CRIS via TELENET
Reply-To: muphaus@cris.com
Message-Id: <kUggkCysSYs8073yn@cris.com>
In-Reply-To: <199410231710.MAA13394@allanon.ia.net>
Lines: 21

Barry wrote:

>It is very difficult to keep from screaming "dumb shit" into the
>microphone.
>
>If this is an indication of where ham radio is going, I'll go
>back to my model trains.

Barry and all...!  This is the reason that all this TAPR HFSIG is being
done on the Internet and not on a 40 meter digital net...  I have been a
ham for 39 years and I have seen it getting worse each year...  It's the
reason that a vast majority of the intelligent hams left ham radio and went
to other endeavors, the technical ones to computers...  So here we are on
the Internet discussing HF radio...   hi hi...

Marv...  K4BVG...

--  Marv Uphaus  --  muphaus@cris.com  --  CompuServe: 72122,1253  --
--  PGP Public Key available in plan  --  finger muphaus@cris.com  --
--  U.S. Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  USA  --
--  Packet Radio: K4BVG @W4IAX.#MOBAL.AL.USA.NA  Ph: 205 343-9256  --
From wdubose@sacdm01.kelly.af.mil  Mon Oct 24 08:55:03 1994
Return-Path: <wdubose@sacdm01.kelly.af.mil>
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzPrE-0000dPC; Mon, 24 Oct 94 08:54 CDT
Received:  by sacdm01.kelly.af.mil (5.65b/1.0.2-rct)
	id AA28372; Mon, 24 Oct 94 08:46:09 -0500
Message-Id: <9410241346.AA28372@sacdm01.kelly.af.mil>
Date: Mon, 24 Oct 94 08:45:58 -0500
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT)
Subject: Re: [HFSIG:41] Re: ASYNC vs Coherent
To: hfsig@tapr.org
Reply-To: sat@sacdm01.kelly.af.mil, [D@sacdm01.kelly.af.mil,
        [D@sacdm01.kelly.af.mil, [Dk5yfw@sat.ampr.org
X-Orig-Date: Sun, 23 Oct 94 02:56 CDT
X-Orig-From: Charles Brain <g4guo@dircon.co.uk>
X-Orig-Message-Id: <199410230752.AA11954@dircon.co.uk>



In Charles  message of 23 Oct 1994 at 0256 CDT, he writes:
> Barry Buelow - WA0RJT <barry@ia.net> writes:
> > I note that some of the comments on ALE refer to async.
> >
> > This thought hasn't been a part of the discussions yet but I thought
> > it would be interesting before we all run off in one direction.
> >

        Charles and All,

Let me address some of these comments and then I'll go back to other
messages and address some others (perhaps).

I don't think the Harris, or Collins-Rockwell ALE units are concerned
withe being Async or Sync...perhaps I'm missing a thought or two
here.  The Fredericks unit is made under license from Harris thus I
would assume it is basically the same unit (cheaper parts? - cheaper
labor?).

>
> Hello Barry,
>
>  Certainly a synchronous system should reduce calling time on air. A small
> on air pool of calling frequencies could be used then after contact has been
> made a QSY to another frequency could be initiated to prevent blocking of the
> calling channels.
>  Non synchronous "ALE" stations could call asynchronously.

I believe that this would be imperative...but how many? 5, 10?  How
wide a channel....5, 1, 1.5, 3 KHz?  Who would decide where they
would be located...hams (by agreement), the FCC in the states or
other regulatory agency elsewhere or perhaps the IARU?  This would
require an accurate receiver and ALE signaling is *not* simply a
short burst.

For those not familiar with the signaling technique let me briefy
describe the process in un-technical terms.

1. The signal is a low baud rate robust signal...this could be made
faster.

2.  Your receiver is "scanning" all the ALE channels (yes...those
frequencies *would* channelize the ham bands) or only those for the
mode you wished to use.  You should be scanning at a specific rate and
if you are scanning more than one band, you need a multi-band
antenna...try this on for 40 & 20 meters.

3.  The signaling transmitter must transmit a query signal on
one channel for a time equal to one complete scan cycle of all the
possible channels.  Then it moves to the next channel and repeats the
process.

Using only four frequencies (channels) in Saudi during the Desert
Twins,  it took more than two minutes (total cycle query time) to try
and establish contact with a station if they never answered.

Can you imagine what it would be like with 10 hams on 20 meters trying
to make an ALE connect on just four voice calling frequencies.  *And*
this does not consider what would happen if someone decided to have a
QSO on the ALE channel or simply was coordinating a move to a working
frequency.  You *would* have to have DSP or sylabic (correct my
spelling if incorrect) squelch to keep from steping on a QSO.  All of
this assumes that you don't have a hidden transmitter...then the
matter really gets stickey.

Calling frequencies in the U.S. have never been used as calling
frequencies but rather "gathering" channels.  How has this worked in
other countries/parts of the world?  Has it worked any better?
Perhaps we in the U.S. are just not as regimented.

>
>  As we are not a military system we can rely on external time sources, in the
> UK we have a transmission on 60 KHz called MSF this is an atomic time standard
> you can buy a kit of parts to build a receiver for about $20. I guess WWV could
> be used in the U.S. While we wait for GPS to drop in price.

Why not include a seperate receiver in the ALE equipment if this is
needed.

>
>  The next problem is to channelise the HAM bands to allow easier handling in the
> database.

Good luck on the HF bands.  See above.

>
>  Another big problem is the Radios themselves, when your rig reads say 14.070Mhz
> what frequency is it actually on.  On SSB the dial frequency should be the
> frequency of the suppressed carrier. The other modes well I dont know.
>  Also it would be nice to disable the input filtering or have solid state switching
> of the filters as when my TS850 scans I hear the relays clicking (and wearing out).

Ah yes...you *WILL* (yes I screamed) need 10 Hz resolution and accuracy and
no drift and let me tell you as chief of communications maintenance
for the militray using the latest state-of-the-are equipment, maintaing
an accurate 10 Hz resolution drift free transceiver is *not* easy and
the equipment is *expensive*.  Tho, software might make this easier,
you would need software that was "rig" specific and assuming all rigs
could be tuned by software/hardware.



> Frequency stability is becoming a big issue especially on modes like
> CLOVER where you have to be within 10 or so Hz of the correct
> frequency and stay there.

See Above.

> It would be nice if all modern radios had an external frequency
> reference input.

This isn't really needed if the units frequency standard is accurate.


>  Timeslots for sounding of stations would have to be arranged so as not to cause
> collisions.

Rgr Rgr...see above

>  The modulation scheme during calling would need to be optimised for :
>  1) Fast recognition.
>  2) Robustness
>  3) Easy to measure S/N, BER, MP etc.
>  4) Measurement of path delay (this could be used to generate simple ionograms)
>

>  A spin off of this of course would be a wonderful beacon system.

I think this is a better solution...a world-wide systems of beacons
to automatically determine band is best with hardware and
software in the users transceiver...making it passive.

All this assumes reciprocity.


> All of this is perfectly possible with modern technology but I
> sometimes wonder if the guys using 5 watts and a hand key don't have
> the right idea.  ALE systems are being developed to reduce the
> skills required of the operator and turn him into a simple
> communicator, operating is much of the fun of HAM radio.

> Bring back spark!

Well, I wouldn't go that far...but basic CW is the basic digital mode.

73,  Walt/K5YFW@work
From wdubose@sacdm01.kelly.af.mil  Mon Oct 24 09:24:42 1994
Return-Path: <wdubose@sacdm01.kelly.af.mil>
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzQK8-0001ULC; Mon, 24 Oct 94 09:24 CDT
Received:  by sacdm01.kelly.af.mil (5.65b/1.0.2-rct)
	id AA29710; Mon, 24 Oct 94 09:16:08 -0500
Message-Id: <9410241416.AA29710@sacdm01.kelly.af.mil>
Date: Mon, 24 Oct 94 09:16:06 -0500
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT)
Subject: Re: [HFSIG:35] Re: ALE
To: hfsig@tapr.org
Reply-To: k5yfw@sat.ampr.org
X-Orig-Date: Sat, 22 Oct 94 12:04 CDT
X-Orig-From: Charles Brain <g4guo@dircon.co.uk>
X-Orig-Message-Id: <199410221657.AA04088@dircon.co.uk>

Again, Greetings.

In Charles message of 22 Oct 1994 at 1204 CDT, he writes:
> k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) writes:
> > Greetings Charles and All,
>
>           If on any of those channels there was a
> >         voice or data QSO going on, it would place its signaling tone on
> >         the frequency it did not recognize it and "stepped" on the QSO.
> >         If critical AE data was being passed, it had to be
> >         re-transmitted.  It really had a way of ruining a QSO as the
> >         signaling took many seconds of transmission time on each
> >         frequency to establish a connection.
>
> Hi Walter,
>  O.K I understand about the problem, The fredricks ALE controller has
> a voice detect function, however as they are only using a TMS320C10
> I guess it is not very effective. As you say this is a problem. I have
> seen an intelligent squelch that uses a DSP in conjunction with a neural
> net to recognise speech on a channel, it takes a few hours to train though.
> Possibly some form of pilot tone SSB would be more suitable. Or the ALE
> could send a "Is the channel free call" I guess there are a lot of diffent
> things that could be done.

I think a sylabelic (check/correct my spelling) squelch such as
Kenwood has on one/some of their Marine HF rigs would be all that is
needed...perhaps a little more but I don't think a lot of DSP is
needed here...perhaps all the voice/data recognitation could be in
one small chip.

>
>  As far as Chelmsford is concerned no I am not a member although I have
> been to the club a couple of times and I am friendly with one of the
> committe members. I will pass on your greetings.
> By the way I work at Mr Guglielmo's Wireless Works in Chelmsford.

For others, I sent a message to Charles referencing my wonderful visit
to the UK several years ago and my visit with the Chelmsford ARC.  If
you ever have an opportunity to visit the UK, have tea (morning,
afternoon, anytime) with the UK hams.  They a most wonderful lot.
Charles works for the Macaroni Radio Works in Chelmsford...a enormous
plant with all sorts of antennae (see Charles, I can spell some things
correctly) sticking up all over the place.


>  As far as packet is concerned I wonder if it would be possible to
> use a DSP based channel conditioner using the HDLC flags as a training
> sequence to reduce the multi-path problems. Also if a data frame has to be
> sent many times it may be possible to store multiple copies of the frame and
> do a majority vote on the data. It should be possible to do this without
> a change in the protocol. There is probably some flaw in my idea.

    This is for programmers and technical types...please take note.


> I do think an improved packet protocol for HF is needed, I know a
> lot of people are thinking about the problem.  I would favour a
> waveform similar to CLOVER i.e using a small number of tones to
> reduce baud rate and a priority ack protocol.

Phil Karn is working on a replacement to AX.25...perhaps his input is
needed here.

I don't think we want to mix a transmission protocol with a modem
protocol...I've never been comfortable with the layered structure so
I don't use it...please excuse this little quirk.

I refer to CLOVER as a modem and transmission protocol.  I like to
keep them seperate...this is a personal thing so just humor me.
While AX.25 may/could use improvement/change/replecement, I'd rather
focus on the modem protocol just a bit.  The Bell 103 standard is a
modem protocol...CLOVER's four parallel tones is a modem protocol,
MIL-STD-188-110c  (U.S. DoD) 39 parallel tone modem is a modem
protocol.  Perhaps we first need to create a modem protocol/modem to
pulg onto existing transmission protocols...AMTOR, RTTY/ASCII, AX.25,
G-TOR, Pactor.  Later adding the transmission protocol.

However, for the programmers, it may be easier to do both.

> As far as the English is concerned, my computer speaks Colonial
> English, anyway my father came from the Canadian Colony so I can
> just about understand you lot!!

73,  Walt/K5YFW@work
From FORRERJ@frl.orst.edu Mon Oct 24 12:02:36 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzSn3-0000sAC; Mon, 24 Oct 94 12:02 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA07589 for <hfsig@tapr.org>; Mon, 24 Oct 1994 02:41:43 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 24 Oct 94 10:02:24 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 24 Oct 94 10:02:01 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 24 Oct 1994 10:01:55 PST8PDT
Subject:       Re: [HFSIG:39] ASYNC vs Coherent
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <5F8C9AD7E20@frl.orst.edu>

Hi Barry

You have a good point here - if we were to lay the groundwork for a new 
system, a synchronous approach would probably have definate 
advantages. (note that synchronous refers to synchronous detection methods -
there also is synchronous symbol detection, that is something different).

In this regard: from what I gather, a GPS receiver would be an ideal 
component in a SS system. Are there any provisions for us doing direct 
sequence SS on HF? What would it take - STA? If we can resolve the details 
on resolving full monitoring capabilities of amateur radio SS on HF (which 
I believe is possible), this may be the answer to our problems. 

Am I just day dreaming, or would it be possible to build a 
RF spreading/despeading subsystem, say taking a 3 Khz voice channel and 
utilizing a slot, say 14.000 - 14.200 Mhz?

73's Johan


  






From FORRERJ@frl.orst.edu Mon Oct 24 12:14:46 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzSxT-0000qMC; Mon, 24 Oct 94 12:13 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA07374 for <hfsig@tapr.org>; Mon, 24 Oct 1994 02:15:55 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 24 Oct 94 9:36:37 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 24 Oct 94 9:36:26 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 24 Oct 1994 09:36:24 PST8PDT
Subject:       Re: [HFSIG:49] Re: ALE
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <5F85C821A8E@frl.orst.edu>

Hi folks,

Wow - I'm pleased to see all the activity. Good stuff!

A few points to respond to:

Sound card details:
-------------------

The sound card that I'm using contains an Analog Devices ADSP-2115 DSP chip 
as well as the standard Windows sound chip, the AD1848. The architecture 
for this low cost board was developed by Analog Devices and named 
the "Personal Sound Architecture" (PSA). Several companies uses this 
chip set on their sound cards, i.e., Cardinal Pro 16 (plus), Orchid 
Soundwave 32, Western Digital, Adaptec, Wearnes Beethoven, Echo Speech. 
There may be others too. 

As far as compatibility is concerned, their digital interface are all the 
same, however, there are some differences in audio circuitry. I have some 
experience with the Cardinal and the Orchid Soundwave 32. They both work 
just fine for DSP dev. work, though are second rate sound cards if that is 
what you are looking for. I bought the Orchid product because it uses the 
latest and fastest revision of the ADSP-2115 DSP chip, i.e., 20 Mhz vs. the 
16 Mhz in the others. The Cardinal Pro 16 is available as low as $80 from 
PC Connection - I paid in the $160 range for the Orchid card. 

As far as DSP software is concerned - I wrote two articles (and Jon 
Bloom and the QEX editorial staff did a great job to make the materials look 
very professional) about this card: The August 1994 issue deals 
with the hardware registers and how to program it using a free software 
toolkit - the second one will appear in the upcoming (November 1994) QEX. 
It shows the implementation of an adaptive 100/200 baud DSP HF modem. I 
think Marv will enjoy that one as it will answer most of his questions. 

The PSA architecture was designed with the upcoming Windows 95 (Chicago) 
DSP API in mind - In the mean time, Analog Devices are giving away free SDK 
for using this card doing DSP development work under Windows. I have 
written a few programs using this platform - however, it requires yet 
another layer of programming and further knowledge of yet another 
programming philosophy to get even something simple working. It 
does work reasonably well. I do believe, however, that for our purposes, we 
would need to stick to writing in assembly and DOS (for a while at least).

Other software that I have available for these PSA cards:

* PSATOR     - AMTOR for the PSA cards (RTTY/ASCII will be added in future)
* PSA-Pactor - Pactor for PSA cards. This is a full rx/tx implementation
             using the adaptive modems mentioned above. It also implements
             full 16-bit memory ARQ in conjunction with brute force search
             algorithms. A 386/25 or better computer is required.
* LMS noise reduction - A port of the W9GR code.

These are shareware and I have attempted to keep the UCSD ftp site up to 
date. However, I will provide copies if you could be so kind to send me a 
formatted disk and SASE/mailer.

I hope this brief reply answers the questions on hardware / software for the 
sound card. There are further software tools available, but I dont want to 
waste further bandwidth on that for the moment.


HF Channel simulator
--------------------

Lets wait till we have had a chance to study the materials. I think Jon and 
Hugh both indicated interest in implementation details, so I am sure that 
we can start exchanging ideas about that shortly.  


ALE performance
---------------

I think I understand that the present implementation of ALE has both a 
routing function as well as a messaging structure. What interest me about 
this protocol, is its modulation scheme - it uses 8-ary FSK and Golay 
(24,12) coding. It would be relatively easy to implement for amateur 
radio application - just a thought: perhaps replacing 300 baud 
packet? 


The future of AX.25
--------------------

Although it may be a while until we progress to the data link layer, I do 
think it would be wise if we pay some attention to these efforts. Please 
keep us posted on what is happening - thanks.  


73's

Johan





From g4guo@dircon.co.uk Mon Oct 24 13:57:57 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzUag-0001BLC; Mon, 24 Oct 94 13:57 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA06299
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 18:54:49 GMT
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA06286; Mon, 24 Oct 1994 18:54:42 GMT
Date: Mon, 24 Oct 1994 18:54:42 GMT
Message-Id: <199410241854.AA06286@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: TENTATIVE PROJECT OUTLINE

"Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu> writes:
> Hi All,
> 
> 
> I trust that you have had an opportunity to look at the modulation
> schemes in Table 1. of my last posting. I thought it would be of
> interest to provide further outlines of those ideas and get some
> discussion and interaction started. Please be so kind and take a
> few moments to study the summary given below.
> 
> Remember, the HFSIG can handle multiple active treads, however,
> please be sure to use an appropriate "subject" when you post your
> replies. This way we will know what your message is about.
> 
Hello Johan et al,

 I joined the net after you posted this could you email it to me or 
re-post it please.

 I was thinking if we use these modems in the rtty sections of the band
we have a shroud idea of the QRM we are going to see.

1) 170Hz FSK
2) 200Hz FSK
3) CW
4) 4 tone ALE
5) Ourselves!

Regards Charles.
From g4guo@dircon.co.uk Mon Oct 24 13:58:10 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzUas-0001BLC; Mon, 24 Oct 94 13:58 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA06290
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 18:54:44 GMT
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA06273; Mon, 24 Oct 1994 18:54:37 GMT
Date: Mon, 24 Oct 1994 18:54:37 GMT
Message-Id: <199410241854.AA06273@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:48] Re: ASYNC vs Coherent

wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) writes:
> 
> 
> In Charles  message of 23 Oct 1994 at 0256 CDT, he writes:
> > Barry Buelow - WA0RJT <barry@ia.net> writes:
> > > I note that some of the comments on ALE refer to async.
> > >
> > > This thought hasn't been a part of the discussions yet but I thought
> > > it would be interesting before we all run off in one direction.
> > >
> 
>         Charles and All,
> 
> Let me address some of these comments and then I'll go back to other
> messages and address some others (perhaps).
> 
> I don't think the Harris, or Collins-Rockwell ALE units are concerned
> withe being Async or Sync...perhaps I'm missing a thought or two
> here.  The Fredericks unit is made under license from Harris thus I
> would assume it is basically the same unit (cheaper parts? - cheaper
> labor?).
> 

Hi Walt,
 The sync part I was refering to was at call setup. All stations in
the net that are able to scan are listening on the same channel at any
time. This means there is no scanning section to the call. An originating
station can estimate the best channel tune and wait, at the right moment
when everyone is listening it makes the call. This also means that everyone
is listening at the most likely time to hear someone else.
 Net synchronisation is vital, in an amateur environment an external sync
source can be used i.e GPS. In a military environment the network has to
self sync. Normaly this consists of starting in async operation, when one 
hears a more senior node in the net that has sync you sync to him etc.
 However when the net starts to get busy performance drops off dramatically.
Sync systems normally have abot 100 channels in the scan group, also every few
minutes a new set of 100 channels are allocated. I have a paper written by
a Prof Carlson in Sweden on this topic.

Regards Charles.
From g4guo@dircon.co.uk Mon Oct 24 14:07:12 1994
Return-Path: <g4guo@dircon.co.uk>
Received: from tdc.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzUjY-0000MCC; Mon, 24 Oct 94 14:07 CDT
Received: from dircon.co.uk (tdc.dircon.co.uk) by tdc.dircon.co.uk with SMTP id AA08208
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 24 Oct 1994 19:04:26 GMT
From: Charles Brain <g4guo@dircon.co.uk>
Received: by dircon.co.uk (5.67b) id AA08195; Mon, 24 Oct 1994 19:04:23 GMT
Date: Mon, 24 Oct 1994 19:04:23 GMT
Message-Id: <199410241904.AA08195@dircon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:51] Re: ALE

"Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu> writes:
> ALE performance
> ---------------
> 
> I think I understand that the present implementation of ALE has both a 
> routing function as well as a messaging structure. What interest me about 
> this protocol, is its modulation scheme - it uses 8-ary FSK and Golay 
> (24,12) coding. It would be relatively easy to implement for amateur 
> radio application - just a thought: perhaps replacing 300 baud 
> packet? 

Hello again,

 It needs tidying up but I have written some C code that does GOLAY (24,12)
as per the MIL STD encoding and decoding. It uses a look-up table to do
the encoding and also another look up that takes the error syndrome and
finds the error vector which you XOR with the original data, it also tells 
you how many errors it has detected so you can either correct or detect.
It seems to work i.e it corrects errors O.K. I used the Parity matrix in
the standard.

Regards Charles
From gjones@tenet.edu Mon Oct 24 14:33:30 1994
Return-Path: <gjones@tenet.edu>
Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzV93-0000zWC; Mon, 24 Oct 94 14:33 CDT
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id OAA22723 for hfsig@tapr.org; Mon, 24 Oct 1994 14:33:23 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199410241933.OAA22723@Kay-Abernathy.tenet.edu>
Subject: Re: [HFSIG:52] Re: TENTATIVE PROJECT OUTLINE
To: hfsig@tapr.org
Date: Mon, 24 Oct 1994 14:33:19 -0500 (CDT)
In-Reply-To: <199410241854.AA06286@dircon.co.uk> from "Charles Brain" at Oct 24, 94 02:04:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2045      

Just as a reminder, all messages from any of the TAPR SIGs are available by
month from the listserv.

Simply send a message to listserv@tapr.org and in the message body state
'index -all'  or in this case 'index hfsig'.

This will then get you a listing of the files that can be requested.

The command for that is:

get area filename

Example:
get tapr taprinfo.txt

This would get you the file taprinfo.txt in the area tapr.  When you do the
index, you will see that the files you want are in an area, so when you do
the get, just fillin the area and filename.

This way, anyone can review the entire SIG from the start.

Cheers - Greg


-----------------------------------------------------------------------------
President -- Tucson Amateur Packet Radio Corp
-----------------------------------------------------------------------------
TAPR Office (817) 383-0000  | Internet: gjones@tenet.edu
-----------------------------------------------------------------------------

According to Charles Brain:
> 
> "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu> writes:
> > Hi All,
> > 
> > 
> > I trust that you have had an opportunity to look at the modulation
> > schemes in Table 1. of my last posting. I thought it would be of
> > interest to provide further outlines of those ideas and get some
> > discussion and interaction started. Please be so kind and take a
> > few moments to study the summary given below.
> > 
> > Remember, the HFSIG can handle multiple active treads, however,
> > please be sure to use an appropriate "subject" when you post your
> > replies. This way we will know what your message is about.
> > 
> Hello Johan et al,
> 
>  I joined the net after you posted this could you email it to me or 
> re-post it please.
> 
>  I was thinking if we use these modems in the rtty sections of the band
> we have a shroud idea of the QRM we are going to see.
> 
> 1) 170Hz FSK
> 2) 200Hz FSK
> 3) CW
> 4) 4 tone ALE
> 5) Ourselves!
> 
> Regards Charles.
> 

From wdubose@sacdm01.kelly.af.mil  Mon Oct 24 14:45:53 1994
Return-Path: <wdubose@sacdm01.kelly.af.mil>
Received: from sacdm01.kelly.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzVKt-0000VFC; Mon, 24 Oct 94 14:45 CDT
Received:  by sacdm01.kelly.af.mil (5.65b/1.0.2-rct)
	id AA07884; Mon, 24 Oct 94 14:37:13 -0500
Message-Id: <9410241937.AA07884@sacdm01.kelly.af.mil>
Date: Mon, 24 Oct 94 14:37:11 -0500
From: wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT)
Subject: Re: [HFSIG:53] Re: ASYNC vs Coherent
To: hfsig@tapr.org
Reply-To: k5yfw@sat.ampr.org
X-Orig-Date: Mon, 24 Oct 94 14:04 CDT
X-Orig-From: Charles Brain <g4guo@dircon.co.uk>
X-Orig-Message-Id: <199410241854.AA06273@dircon.co.uk>

Charles,

In your message of 24 Oct 1994 at 1404 CDT, you write:
> wdubose@sacdm01.kelly.af.mil (WALTER (WALT) D. DUBOSE - PKT) writes:
> >         Charles and All,
> >
> > Let me address some of these comments and then I'll go back to other
> > messages and address some others (perhaps).
> >
> > I don't think the Harris, or Collins-Rockwell ALE units are concerned
> > withe being Async or Sync...perhaps I'm missing a thought or two
> > here.  The Fredericks unit is made under license from Harris thus I
> > would assume it is basically the same unit (cheaper parts? - cheaper
> > labor?).
> >
>
> Hi Walt,
>  The sync part I was refering to was at call setup. All stations in
> the net that are able to scan are listening on the same channel at any
> time. This means there is no scanning section to the call. An originating
> station can estimate the best channel tune and wait, at the right moment
> when everyone is listening it makes the call. This also means that everyone
> is listening at the most likely time to hear someone else.
>  Net synchronisation is vital, in an amateur environment an external sync
> source can be used i.e GPS. In a military environment the network has to
> self sync. Normaly this consists of starting in async operation, when one
> hears a more senior node in the net that has sync you sync to him etc.
>  However when the net starts to get busy performance drops off dramatically.
> Sync systems normally have abot 100 channels in the scan group, also every few
> minutes a new set of 100 channels are allocated. I have a paper written by
> a Prof Carlson in Sweden on this topic.


I'd really hate to tie my HF operation to the presence of a satellite...
If I'm going to do that, I might as well get a nitch on a geosync
bird and send 19.2 data and to heck with HF.  Besides will I now have
to have two receivers, coax and antennas just to work HF.  And too,
my truck is already filled with radio equipment and antennas..I will
now need another "rig" and antenna on/in the truck and will have to
park in the hot sun to work HF...not under a cool shade tree cause I
gotta receive the satellite.

The reason many U.S. military units use HF is they don't want to
depend on a satellite...their *too easy* to knock out.

Realizing that GPS boxes are and will come down in price, and I'll
need another box for the ALE, I'll soon have a bunch of money in
equipment.

If we don't watch out, an HF rig will cost 2000 PS.

I might add...where's the KISS?

Walt/K5YFW
From barry@ia.net Mon Oct 24 22:53:48 1994
Return-Path: <barry@ia.net>
Received: from allanon.ia.net by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0qzcxD-0001S0C; Mon, 24 Oct 94 22:53 CDT
Received: from localhost (barry@localhost) by allanon.ia.net (8.6.5/8.6.5) id WAA12461 for hfsig@tapr.org; Mon, 24 Oct 1994 22:53:37 -0500
From: Barry Buelow - WA0RJT <barry@ia.net>
Message-Id: <199410250353.WAA12461@allanon.ia.net>
Subject: Re: [HFSIG:50] Re: ASYNC vs Coherent
To: hfsig@tapr.org
Date: Mon, 24 Oct 1994 22:53:36 -0500 (CDT)
In-Reply-To: <5F8C9AD7E20@frl.orst.edu> from "Johan Forrer                                                                             FL" at Oct 24, 94 12:06:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1841      

> 
> Hi Barry
> 
> You have a good point here - if we were to lay the groundwork for a new 
> system, a synchronous approach would probably have definate 
> advantages. (note that synchronous refers to synchronous detection methods -
> there also is synchronous symbol detection, that is something different).

exactly what I was thinking.  tx and rx in at least freq sync and possibly
in phase sync.
> 
> In this regard: from what I gather, a GPS receiver would be an ideal 
> component in a SS system. Are there any provisions for us doing direct 
> sequence SS on HF? What would it take - STA? If we can resolve the details 
> on resolving full monitoring capabilities of amateur radio SS on HF (which 
> I believe is possible), this may be the answer to our problems. 
> 

It seems to me that any serious improvement is hf throughput is not
going to come from an inexpensive chrome box that plugs in to the mic 
and speaker jacks.  

There is a cascading effect.   Good throughput requires good freq/time
stability.  99.99% of off the shelf rigs do NOT support external freq
references.  

Without addressing SS for now, this leads to a total system design:
timebase, tx, rx, modem.  Consider that a good system out to be 
something in the 50 to 100W range, and doesn't need all the chrome
and knobs of typical modern radios, single band or a couple of bands,
what else?

This is a rather substantial design task, but it brings all the important
technical issues into play.  Major flexibility of operation issues are
not a design requirement.

If this system cost $1000, it would be a huge bargain.

> Am I just day dreaming, or would it be possible to build a 
> RF spreading/despeading subsystem, say taking a 3 Khz voice channel and 
> utilizing a slot, say 14.000 - 14.200 Mhz?
> 
> 73's Johan
> 
Just dreaming along...

73 Barry



From shane@mdd.comm.mot.com Tue Oct 25 23:35:15 1994
Return-Path: <shane@mdd.comm.mot.com>
Received: from motgate.mot.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r004t-0000uPC; Tue, 25 Oct 94 23:35 CDT
Received: from mothost.mot.com ([129.188.137.101]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA25218; Tue, 25 Oct 1994 20:24:26 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by mothost.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA15114; Tue, 25 Oct 1994 12:31:36 -0500
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA02407; Tue, 25 Oct 94 10:03:33 PDT
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA19089; Tue, 25 Oct 94 10:03:31 PDT
Date: Tue, 25 Oct 1994 10:03:26 -0700 (PDT)
From: Hugh Shane <shane@mdd.comm.mot.com>
X-Sender: shane@daffyduck
To: hfsig@tapr.org
Subject: Re: [HFSIG:51] Re: PSA
In-Reply-To: <5F85C821A8E@frl.orst.edu>
Message-Id: <Pine.SUN.3.90.941025091408.15133A-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Mon, 24 Oct 1994, Johan Forrer FL wrote:

> 
> As far as compatibility is concerned, their digital interface are all the 
> same, however, there are some differences in audio circuitry. I have some 
> experience with the Cardinal and the Orchid Soundwave 32. They both work 
> just fine for DSP dev. work, though are second rate sound cards if that is 
> what you are looking for. I bought the Orchid product because it uses the 

Is the audio interface on these cards sufficient for digital communication?

> 
> The PSA architecture was designed with the upcoming Windows 95 (Chicago) 
> DSP API in mind - In the mean time, Analog Devices are giving away free SDK 
> for using this card doing DSP development work under Windows. I have 
> written a few programs using this platform - however, it requires yet 
> another layer of programming and further knowledge of yet another 
> programming philosophy to get even something simple working. It 
> does work reasonably well. I do believe, however, that for our purposes, we 
> would need to stick to writing in assembly and DOS (for a while at least).
> 

How about Linux? With it's multitasking capabilities, Linux is an excellent
platform for packet. And, of course, for software development you can't
beat Unix. All we need are Linux driver for the Personal Sound
Architecture and Unix-hosted development tools. 

> Other software that I have available for these PSA cards:
> 
> * PSATOR     - AMTOR for the PSA cards (RTTY/ASCII will be added in future)
> * PSA-Pactor - Pactor for PSA cards. This is a full rx/tx implementation
>              using the adaptive modems mentioned above. It also implements
>              full 16-bit memory ARQ in conjunction with brute force search
>              algorithms. A 386/25 or better computer is required.
> * LMS noise reduction - A port of the W9GR code.

How about K9NG/G3RUH modulation? (I'm also putting together a node for our 
local VHF TCP/IP network.)

	73
	Hugh
From FORRERJ@frl.orst.edu Wed Oct 26 10:38:09 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0AQQ-00015nC; Wed, 26 Oct 94 10:38 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA18116 for <hfsig@tapr.org>; Wed, 26 Oct 1994 01:17:10 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 26 Oct 94 8:37:56 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 26 Oct 94 8:37:40 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 26 Oct 1994 08:37:40 PST8PDT
Subject:       Re: [HFSIG:58] Re: PSA
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <62763272701@frl.orst.edu>

Hugh,

My experiences with the audio of the sound card tells me that its 
more than adequate for our usage. The modems that I have played with 
only runs at a minimal sampling rate of 5.5125 kHz and I have found 
the anti-aliasing/recon filters very effective to be able to run at that 
low sample rate. The LMS noise reducer runs at about 19 kHz and the audio 
quality is quite good, if not better than the commercial boxes doing the 
same thing. The only thing that the card does not have is digital I/O. 
However, someone with a bit of ingenuity can fabricate a "port". I use a 
serial port on the host for that purpose in the interim.

Tom, HB9JNX has written 1200 and 9600 baud packet modems for the card - I 
have no further details except knowing of its exsistance. I do know, 
however, that he told me that he built a direct interface to the DSP's 
"SPORT" for data I/O. So - it can be done. Tom has been very quiet 
lately, so I dont know the status of that project of his. It would be real 
nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
should be the one do it?
 
I hope to post a summary on materials that I have been working on regarding 
modulation schemes and possible ways of debugging/evaluating the system, 
by monday. 

Please give your thoughts on your DSP platform high priority - the learning 
curve is real steep and we will be starting to do some real stuff in the 
very near future. Let me assure you - there is a lot of fun ahead!


Hope I addressed all the questions.

73's 

Johan

From FORRERJ@frl.orst.edu Wed Oct 26 10:52:24 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0AeE-0001GGC; Wed, 26 Oct 94 10:52 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA18184 for <hfsig@tapr.org>; Wed, 26 Oct 1994 01:31:31 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 26 Oct 94 8:52:17 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 26 Oct 94 8:52:12 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 26 Oct 1994 08:52:11 PST8PDT
Subject:       Re: [HFSIG:58] Re: PSA
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <627A1243BB7@frl.orst.edu>

Hugh,

About Linux - I have a system that is used for experimentation. And I do 
think that it has tremendous capabilities, unfortunately, however, it is a 
very fast moving target and I have found myself maintaining the OS more 
than doing any exiting DSP development work. A DSP platform for Linux will 
probably require a kernel hack similar to the AX.25 project for Linux - You 
really have to know what you are doing. I do believe that one could 
probably put something really nice together.

On the other hand - if you are interested in wider audience, Linux is 
somewhat out on a limb. There really is only one fellow doing the sound 
drivers (and he has quit doing that), and from what I gathered, it is quite 
generic - a far cry from trying to actually run your own DSP code on your 
sound card. On the other side of the coin, with the battle going on between 
the Microsoft and OS/2 worlds, something useful may emerge. In following the 
DSP API developments for these new OS's it appears there are some 
good things in stall - of coarse not for ham radio, but for multimedia 
running on DSP's. Fortunately we will be able to fit right into the picture 
with our work. So have good faith.  

Sorry for the distraction - this has little to do with HF digital but 
thought I would give my two cents worth.

--Johan










From shane@mdd.comm.mot.com Wed Oct 26 12:40:34 1994
Return-Path: <shane@mdd.comm.mot.com>
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0CKu-0001QRC; Wed, 26 Oct 94 12:40 CDT
Received: from pobox.mot.com ([129.188.137.100]) by ftpbox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA12114; Wed, 26 Oct 1994 12:40:21 -0500
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
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Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA25083; Wed, 26 Oct 94 10:39:02 PDT
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA15389; Wed, 26 Oct 94 10:39:01 PDT
Date: Wed, 26 Oct 1994 10:39:00 -0700 (PDT)
From: Hugh Shane <shane@mdd.comm.mot.com>
X-Sender: shane@daffyduck
To: hfsig@tapr.org
Subject: Re: [HFSIG:59] Re: PSA
In-Reply-To: <62763272701@frl.orst.edu>
Message-Id: <Pine.SUN.3.90.941026101729.15133C-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



> lately, so I dont know the status of that project of his. It would be real 
> nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
> should be the one do it?

This would be a tasty project indeed! Is this the appropriate place to 
begin a discussion on this topic, or is there another SIG that would be 
better.

> 
> Please give your thoughts on your DSP platform high priority - the learning 
> curve is real steep and we will be starting to do some real stuff in the 
> very near future. Let me assure you - there is a lot of fun ahead!
> 

In comparing DSP platforms I consider performance, features,
compatibility, price, and availability. IMHO, for our purposes, there are
only two contenders for a DSP platform at this time: the PSA-class boards
and the TAPR DSP-93. The PSA solution has adequate performance, is
reasonably priced and available now. However, it only works with ISA/EISA
machines and is not code compatible with the TAPR product, which has a
large code base that is certain to grow in the future. On the other hand,
the TAPR board is twice as expensive as the PSA boards and has a lead time
of half a year.

If I didn't care about what the rest of the ham radio world was doing I'd
go with the PSA solution. But I *do* care! Does it make sense to not take
advantage of a potentially huge pool of code? Or maybe we should just
start our own faction which will have its own devotees and its own code
base.  Maybe in time this will become the winning solution due to the low
price and general availability of the hardware. 

I think I'll continue to sit on the fence a little while longer. Can someone 
push me off?

	Hugh
From FORRERJ@frl.orst.edu Wed Oct 26 13:40:32 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0DGu-0001UVC; Wed, 26 Oct 94 13:40 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id EAA19653 for <hfsig@tapr.org>; Wed, 26 Oct 1994 04:19:36 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 26 Oct 94 11:40:23 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 26 Oct 94 11:40:05 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 26 Oct 1994 11:40:01 PST8PDT
Subject:       Re: [HFSIG:61] Re: PSA
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <62A6D8F00FF@frl.orst.edu>

Hugh,

I see no problem discussing the 9600 baud modem stuff here, though think 
that if it concerns implementation details, the DSP development SIG 
would be the right place and may appeal to a wider audience. I think 
you will get a lot more support there too.

In a future posting (hopefully by monday), I hope to include some important 
aspects that differentiates the VHF style DSP modems from the 
intended robust HF DSP modems. They have lots of similarities. i.e. 
phase and symbol synchronous, carrier & data extractors from supressed-
carrier modulation systems, however, require careful design of signal 
constallation, and particulaly, robust phase locking - these are much 
more important than speed. But more on this later.


Johan  









From gjones@tenet.edu Wed Oct 26 14:44:30 1994
Return-Path: <gjones@tenet.edu>
Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0EGp-0001RzC; Wed, 26 Oct 94 14:44 CDT
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id OAA09751 for hfsig@tapr.org; Wed, 26 Oct 1994 14:44:22 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199410261944.OAA09751@Kay-Abernathy.tenet.edu>
Subject: Re: [HFSIG:61] Re: PSA
To: hfsig@tapr.org
Date: Wed, 26 Oct 1994 14:44:21 -0500 (CDT)
In-Reply-To: <Pine.SUN.3.90.941026101729.15133C-100000@daffyduck> from "Hugh Shane" at Oct 26, 94 12:47:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 4241      

According to Hugh Shane:
> > lately, so I dont know the status of that project of his. It would be real 
> > nice if we can make a 9600/G3RUH modem available for the card. Perhaps you 
> > should be the one do it?
> 
> This would be a tasty project indeed! Is this the appropriate place to 
> begin a discussion on this topic, or is there another SIG that would be 
> better.

I think you will find that the cards do not have any enough power to handle
the 9600 baud full-duplex transmission.  From what I have been told it is
doubtfull that half-duplex can be done..maybe somebody can reply to this.

This does not stop doing a lower baud with more bps, but current standards
favor FSK, for a lot of reasons.  I would point you at some of the last TAPR
prcoeedings and ARRL DCC articles on 2 and 4 FSK and PSK and the like
performance possibilities.
 
> > Please give your thoughts on your DSP platform high priority - the learning 
> > curve is real steep and we will be starting to do some real stuff in the 
> > very near future. Let me assure you - there is a lot of fun ahead!
> 
> In comparing DSP platforms I consider performance, features,
> compatibility, price, and availability. IMHO, for our purposes, there are
> only two contenders for a DSP platform at this time: the PSA-class boards
> and the TAPR DSP-93. The PSA solution has adequate performance, is
> reasonably priced and available now. However, it only works with ISA/EISA
> machines and is not code compatible with the TAPR product, which has a
> large code base that is certain to grow in the future. On the other hand,
> the TAPR board is twice as expensive as the PSA boards and has a lead time
> of half a year.

With hope, a mfg will pick up the DSP-93 design and mfg it for much less
than what we are doing it for as kits.    The reason for doing the DSP-93 is
not to make money at selling kits, but to open up the technology (which 
has been the goal since 1988).  With the DSP-12 from LL Grace leaving the
market that now leaves the AEA units as the only commerically available
unit (from amateur suppliers).

I don't know if you can remember back to the TNC-2 introduction, but those 
kits were sold for $250+ and within two years were available for $150.  
We hope that the DSP-93 technology can happen in the same way.  If the unit 
is done as all SMA technology and as one board and is done outside the US, 
I figure that cost would  a lot less than what we can do it in small qtys 
and as kits.  

So - if you like the design, and dont want to either 1) wait for a kit and
2) spend $430 (which is a bargin for what it does) then you should be
calling up your favored mfg and asking him when they are going to talk to tapr
about OEMing the technology :-)

> If I didn't care about what the rest of the ham radio world was doing I'd
> go with the PSA solution. But I *do* care! Does it make sense to not take
> advantage of a potentially huge pool of code? Or maybe we should just
> start our own faction which will have its own devotees and its own code
> base.  Maybe in time this will become the winning solution due to the low
> price and general availability of the hardware. 

I think you will see that code is developed for all platforms and a lot of
it will be ported between systems.  The reason for going with one solution
or another is what you want to do.  If you need two radio ports, the
interface to the radios, and processor and power to do 9600 baud full-duplex
or the like then the DSP-93 is a solution.  

If you want to do modulations that require the A/D power but not
all the processor power than a sound card is a good solution.  Just don't
forget that with the sound card you still need all the radio interface
depending on what you are wanting to do...that is one reason the DSP-93 is
more expensive to start with - it has all the interface builtin.

> I think I'll continue to sit on the fence a little while longer. Can someone 
> push me off?

Probably not a bad decision.  If you have a modem you are happy with now,
then you should stick with it.  You will want to purchase a DSP unit if 1)
you want to experiment and 2) there is a new mode that requires it.
No need to purchase something that will sit around.

Cheers - Greg
From FORRERJ@frl.orst.edu Wed Oct 26 15:02:07 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
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Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id FAA20172 for <hfsig@tapr.org>; Wed, 26 Oct 1994 05:41:14 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 26 Oct 94 13:01:33 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 26 Oct 1994 13:01:31 PST8PDT
Subject:       Re: [HFSIG:63] Re: PSA
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <62BC9234604@frl.orst.edu>

Hi Greg,

Could you pse post the actual reference to DCC and TAPR docs that have the 
FSK/PSK performance specs for everyone's benefit - would be great - thanks.

-Johan
From FORRERJ@frl.orst.edu Thu Oct 27 14:54:15 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0atn-00017OC; Thu, 27 Oct 94 14:54 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id FAA25364 for <HFSIG@tapr.org>; Thu, 27 Oct 1994 05:33:11 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 27 Oct 94 12:53:53 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Thu, 27 Oct 1994 12:53:49 PST8PDT
Subject:       DEMODULATOR TESTING ETC.
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <643A91E04AC@frl.orst.edu>

Hi all,

Thanks for the words of encouragement - the HFSIG is only what we make 
it to be and it is heartwarming to see that there still is amateur spirit 
to push the envelope. 

Re: the DSP platform: I hope we dont waste too much time on a silly issue 
of who has more marbles. The DSP soundcard will do 9600 baud - I dont know 
who told Greg otherwise, just to put the record straight - look at the 
Scout 14.4K modems, they use the same family DSP chip. Trying to compare 
these platforms are like comparing a Caddy to a Jeep - both will do 90 on 
the freeway, but they are ultimately for different purposes. The DSP-93 has 
excellent capabilities - especially a capable strong support group - that 
is vital if you are just starting out - lots of "free" software - and 
it could be used as a free-standing DSP box. I hope they get all the support 
to make their efforts worthwhile - that box must succeed. 

However, for those that are going to become deeply involved in the 
development and testing aspects, the DSP development platform requirements 
are going to become much more complex - for example, the real-time channel 
simulator probably will be running on its own DSP processor with input - 
output channels to take the signal from the modulator, add the simulated 
effects, and play it out in real time on the output channel to the 
demodulator under test. This probably means a DSP platform for the 
modulator and another for the demodulator. Add to that DSP diagnostic 
tools, i.e. to display parts of the signal or constallations, logging of 
results etc.... That adds up to two PC platforms and three DSP development 
systems. Perhaps you will now understand why I am using $80 sound DSP sound 
cards. If anyone can suggest another approach, I'll be really interested. 

However, if you are only planning to participate in actual over the air 
testing, a modest PC, i.e. 486/33 and either a DSP-93 or DSP sound card 
will do just fine. At this level, I am confident that code for either 
approach will be made available for you to participate in these tests.   

By monday I'll put forward a rough proposal on something that we can start 
working on - unfortunately we do not have anything yet on the simulator, but 
I have good faith that we can put something very rudimentary together that 
will do for starters. If we keep things generic, and write algorithms in 
psuedo-code, it really wont matter what platform you are going to use at 
this early stage. Actually, if we follow this approach, you can even write 
the test code in "C" and run it on your PC - it will be a lot slower and 
you wont get the same statistical sampling, but all we need to establish 
initially are the working tolerances for some of the major components.  
Hopefully things will be a lot clearer after seeing the plan.  

I also encourage folks to discuss other topics besides the digital issues - 
please feel free to do so. Also if you have other ideas on how to go about 
this journey - let us have your opinions/suggestions. 

73's

Johan
From muphaus@cris.com  Thu Oct 27 22:11:34 1994
Return-Path: <Muphaus@cris.com>
Received: from cris.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0hj3-0000a5C; Thu, 27 Oct 94 22:11 CDT
Received: from starcore.cris.com by cris.com [1-800-745-CRIS (voice)]
Received: by starcore.cris.com (4.1/SMI-4.1)
	id AA02218; Thu, 27 Oct 94 23:11:19 EDT
To: hfsig@tapr.org
From: muphaus@cris.com (Marv Uphaus)
Subject: Re: [HFSIG:65] DEMODULATOR TESTING ETC.
Date: Thu, 27 Oct 1994 20:38:29 -0500
Organization: CRIS via TELENET
Reply-To: muphaus@cris.com
Message-Id: <LO5ikCysS-LT073yn@cris.com>
In-Reply-To: <643A91E04AC@frl.orst.edu>
Lines: 18

>However, if you are only planning to participate in actual over the air
>testing, a modest PC, i.e. 486/33 and either a DSP-93 or DSP sound card
>will do just fine.

Now, Johan...
Only a few months ago an 8088 would have been a "modest PC"...
hahaha...  My, how our perspective changes...!!!

>I also encourage folks to discuss other topics besides the digital issues -

See above...  hahaha...

Marv...

--  Marv Uphaus  --  muphaus@cris.com  --  Ph: 205-343-9256  --
--  PGP Public Key available  --  "finger muphaus@cris.com"  --
--  U.S.Mail: 4031 Airport Blvd. #49  --  Mobile, AL  36608  --
--  Packet Radio Address  --  K4BVG @W4IAX.#MOBAL.AL.USA.NA  --
From gjones@tenet.edu Fri Oct 28 15:30:39 1994
Return-Path: <gjones@tenet.edu>
Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0xu6-0001LMC; Fri, 28 Oct 94 15:28 CDT
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id MAA14326 for hfsig@tapr.org; Fri, 28 Oct 1994 12:56:00 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199410281756.MAA14326@Kay-Abernathy.tenet.edu>
Subject: Re: [HFSIG:65] DEMODULATOR TESTING ETC.
To: hfsig@tapr.org
Date: Fri, 28 Oct 1994 12:55:59 -0500 (CDT)
In-Reply-To: <643A91E04AC@frl.orst.edu> from "Johan Forrer                                                                             FL" at Oct 27, 94 02:57:00 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 2329      

According to Johan Forrer                                                                             FL:
> Re: the DSP platform: I hope we dont waste too much time on a silly issue 
> of who has more marbles. The DSP soundcard will do 9600 baud - I dont know 
> who told Greg otherwise, just to put the record straight - look at the 
> Scout 14.4K modems, they use the same family DSP chip. Trying to compare 
> these platforms are like comparing a Caddy to a Jeep - both will do 90 on 
> the freeway, but they are ultimately for different purposes. The DSP-93 has 
> excellent capabilities - especially a capable strong support group - that 
> is vital if you are just starting out - lots of "free" software - and 
> it could be used as a free-standing DSP box. I hope they get all the support 
> to make their efforts worthwhile - that box must succeed. 

I would be real interested in knowing if anyone has 9600 baud FSK
implemented on a card device.  From my conversations with crystal
semiconductor, makers of several of the devices for the sound card industry,
they felt that 9600 baud was outside the processing power of the many of the
current low-cost devices.

Please keep in mind that 14.4Kbps is 1200 baud with 12 bits of encoding.
The problem we have in amateur radio applications with expanding the numbers
of bits per baud is the medium we are using - radio.  Radio and telephonic
operations are considerably different and the S/N must be very good in
order to be able to handle the higher order encoding methods.

One thing we should keep in mind is the work Phil Karn is doing on using FEC
and symbol rates in such a way to provide some rather robust links.

Both Phil's and Tom's papers on these topics were published in
the TAPR 1994 Proceedinsg, which I think sells for $7.  I am always
forgetting what stuff goes for.

I think we agree that none of us should be getting into pissing contests on
performance issues.  The idea of any discussion, I would hope within TAPR,
would be to do the research, make the informationl available, and then try
to implement it in something that provides the widest possible access to
amateurs in the community.

The other main reason for not really worrying about performance issues is
that whatever we have now - will be 2+ folds more powerful in 5 years.

Cheers - Greg

From jbloom@arrl.org Fri Oct 28 15:43:21 1994
Return-Path: <jbloom@arrl.org>
Received: from uu7.psi.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r0y2e-000166C; Fri, 28 Oct 94 15:36 CDT
Received: from mgate.arrl.org by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
        id AA20140 for hfsig@tapr.org; Fri, 28 Oct 94 09:40:46 -0400
Received: from arrl.org by mgate.arrl.org with smtp
	(Smail3.1.28.1 #6) id m0r0rVp-000B9bC; Fri, 28 Oct 94 09:38 EDT
Received: by arrl.org with Microsoft Mail
	id <2EB1002A@arrl.org>; Fri, 28 Oct 94 09:44:10 EDT
From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:65] DEMODULATOR TESTING ETC.
Date: Fri, 28 Oct 94 09:42:00 EDT
Message-Id: <2EB1002A@arrl.org>
Encoding: 28 TEXT
X-Mailer: Microsoft Mail V3.0


Johan says:
> If we keep things generic, and write algorithms in
>psuedo-code, it really wont matter what platform you are going to use at
>this early stage. Actually, if we follow this approach, you can even write
>the test code in "C" and run it on your PC - it will be a lot slower and
>you wont get the same statistical sampling, but all we need to establish
>initially are the working tolerances for some of the major components.

This is what I'm most interested in: developing and documenting the 
algorithms needed to implement all the neat things people are dreaming up, 
including the HF channel simulator and faster HF modems, but not limited to 
those applications. The algorithms can be documented in pseudo-code, flow 
charts, SDL or whatever seems appropriate. Then the algorithm can be 
implemented on multiple platforms. My feeling is that we should strive, 
where possible, to do work that is platform independent, _then_ transfer 
that work to an implementation on a specific platform. If we do a good 
algorithm design up front, it will shortly appear as an implementation on 
several platforms; there are enough programmers to make that happen.

And, of course, I'd like to see the algorithms documented in QEX!  :-)

Regarding the HF channel simulator... it's main use (for us) is to test 
other DSP modems, so clearly it has to be running on a separate platform. 
The TI DSK strikes me as a good, cheap stand-alone platform. But, as I say, 
if we get the algorithms documented, the choice of platform is easier.

 -- Jon, KE3Z
From FORRERJ@frl.orst.edu Fri Oct 28 18:04:07 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r10L4-0001hRC; Fri, 28 Oct 94 18:04 CDT
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA02366 for <hfsig@tapr.org>; Fri, 28 Oct 1994 08:42:28 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 28 Oct 94 16:03:24 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 28 Oct 94 16:03:13 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 28 Oct 1994 16:03:07 PST8PDT
Subject:       Re: [HFSIG:67] Re: DEMODULATOR TESTING ETC.
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <65ED1C42400@frl.orst.edu>

Hi Greg,

You quite correctly pointed out the challenge of 9600 baud FSK  - I do agree 
that what we presently have, would not have enough ticks to do that - 
thanks for clearing that up.

I would like you to consider some ideas on how we can achieve reasonable bit 
rates based on low baud rates and multiple phase / multiple amplitude 
modulation, i.e. complex modulation.  This would be within the capabilities 
of what we have right now. We need however, address the variablities of the 
HF channel and its affects on such a scheme. I'll put out some ideas on 
monday on the possible use of a "pilot" channel that goes out in parallel 
with the data channel to aid in phase/amplitude equalization for such 
complex modulated schemes. This is not a unique idea either.

Oh yes, quite true - coding theory will come in a bit later in the game, 
but should not be a bandaid for a poor modulation, it should buy us that 
few extra bits "gain" on top of what we have achieved with a good 
modulation scheme.


73's

Johan
From k5yfw@k5yfw.ampr.org  Fri Oct 28 20:56:01 1994
Return-Path: <k5yfw@k5yfw.ampr.org>
Received: from k5yfw.ampr.org by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r130c-0000q5C; Fri, 28 Oct 94 20:55 CDT
Date: Fri, 28 Oct 94 20:19:23 CST
Message-Id: <2123@k5yfw.ampr.org>
From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW)
Reply-To: k5yfw@sat.n5lyt.ampr.org
To: hfsig@tapr.org
Subject: HF Modulation
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS)

Greetings HFers,

I thought I'd try and re-name this thread from DEMODULATION to
Modulation.  Realizing however, that both are needed and in complex
modems and both creating the modulator and detector on a sound card is
going to be a challange.

For those who have gotten in "late", Johan and I have been discussing
robust, high speed modems for almost a year and Greg and I have been
carrying on a dialog for several months now.

I have used commercial/military equipment on HF at 2400 and 4800 BPS
that were *very* robust modems.  We even ran on-the-air tests against
SITOR (the commercial version of AMTOR) over the same channel.  The high
speed modems beat SITOR in transferring data at a factor greater than
the difference in bit rate.  That is to say that at 2400 BPS for the
robust HF modem we had 100% thruput at 2400 BPS.  It was capable of 2400
BPS data transfer rate and it transfered 2400 bps.  On SITOR, we had
less than 100% of the possible thruput rate.  In Jan of 1990, the modem
cost $15,000.  Today you can get it for $3,200.

I have seen the block diagram and chips it has and it "looks" like a
sound card and has the same type DSP & ASP chips as soundcards.  While
probably would not want to just emulate that modem, we should improve on
the design, we should make it a goal as we know it is achievable.

Many of my friends ask me why I hate CLOVER.  I tell them that I don't
but feel for that amount of money, hams should get more BPS for their
buck.  Hear's the reason.  CLOVER uses 4 parallel tones to get 800-900
BPS.  The commercial/military modems use 39 tones to get 2400 BPS with
the 40th tone as an unmodulated/standard modulated pilot/doppler tone.
I believe that some where between 4 and 40 tones hams (those of you who
are much smarter than I) can come up with a modem for HF that will be
very robust and produce 1200-2400 (and maybe more) BPS in a BW that is
less than the commercial/military modem.

If the guys who will do the actual programming "max-out" the soundcard
and produce a robust, 2400 BPS (100 baud or less) HF modem and can apply
the the same principle to a V/UHF modem and get 9600/19.2K BPS, ham
radio will have greatly benefited.  If they can produce only 1200 BPS on
HF and 4800 or 9600 on V/UHF, thats Ok too...just max-out the sound
cards capability.  By then, perhaps better sound cards and/or other
devices will be on the market that will let us go higher.

I like the picture of the frog choking the water fowl while the frog's
head in in the bird's mouth.  The caption is never give up.  Don't give
up, try hard, keep it low cost and KISS.

73 & have a nice weekend ya'll.

Walt@home (dba k5yfw)
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Received: from localhost by dub-img-2.compuserve.com (8.6.4/5.940406sam)
	id AAA29239; Mon, 31 Oct 1994 00:35:29 -0500
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Hi all,

It is not quite so obvious which "magic" technology we should pursue 
that will give maximum gains. Well, perhaps there is no magic answer,
or at least; those that know better won't say either or won't be
bothered. Lets face it, most everything that we are about to
embark on, have been done before in one form or another
commercially - though I am not aware of anything affordable for 
amateurs to experiment with (yes, Clover could have been the
answer, except that it was developed as a "closed" architecture).

How one chooses one modulation/demodulation scheme over another,
is an extensive and interesting topic by itself. Without going
into much details, let me take an easy way out and go by what
others have achieved, that is, m-FSK to approx 300 bps and (nxm)-
PSK for higher rates. These have been found to be quite usable on
HF. 

The m-FSK option, i.e. a system similar in modulation and coding
than what is presently implemented for ALE, would be quite do-
able on our present DSP platforms. Anyone interested in that? 

Nxm-PSK is a multitone approach. In this scheme, there are
several (n- of them) independent m-PSK carriers. As far as
development is concerned, one can concentrate your development
efforts on getting the most out of one carrier, then add
additional carriers as far as your DSP horsepower will take you,
or perhaps until you run out of bandwidth (suspect the DSP is the limiting
factor). The parallel deal is to be used to get maximal bit rate as conditions
permit, or
serve for additional redundancy when conditions are not so good.
This basically is the premise used for the MIL-STD-188 parallel
modems. I would (rather bravely) like to suggest that this
alternative be pursued - unless of course you could suggest a
better alternative. Please let me know your opinion on this one.

Assuming the nxm-PSK approach in its simplest form, how does it sound if we
develop a single m-PSK channel and see how far that takes
us. ?

I would suggest as background, obtaining the following three
papers (these are heavy duty, but quite good):

1) Foschini, G.J., R.D. Gitlin, and S.B. Weinstein. "On the
Selection of a Two-Dimensional Signal Constellation in the
Presence of Phase Jitter and Gaussian noise." Bell System Tech.
Jour. Vol. 52(6) July-August 1973 pp:927-965.

2) Simon, M.K., and W.C. Lindsey. "Optimum Performance of
Suppressed Carrier Receivers with Costas Loop Tracking". IEEE
Trans. on Communications Vol. COM-25(2) February 1977 pp:215-227.

A more complete and realistic treatment of the performance of
different modulation schemes and of phase lock loops in the
presence of noise and phase jitter are also given in the above
authors' book: "Telecommunications Systems Engineering." Dover
pubs. ISBN 0-486-66838-X.

3) Simon, M.K. and J.G. Smith. "Carrier Synchronization and
Detection of QASK Signal Sets." IEEE Trans. on Communications
Vol. COM-22(2) February 1974.

It is evident, at least to me, that carrier phase synchronization 
and amplitude equalization becomes quite important when dealing with 
these complex (meaning quadrature) waveforms. The idea of using a separate 
"pilot" channel that carries such phasing and clock data, seems rather
attractive. Not 
only will it simplify implementation details, but probably allow us to 
be able to track multipath effects. The additional robustness in system
performance
that it would add, would offset its small amount of additional
bandwidth. Let me have your views on this one too. Also think a
bit about what information need to be encoded in the "pilot"
carrier.


73's 

Johan



PS: Thanks to Walt for forwarding a wealth of details over an extended period on
the MIL-STD-188 modems. We certainly have beaten its possibilities to death. The
use of the pilot tone, or doppler channel as they call it, is used in both the
39-tone as well as
the 16-tone modems.

I must also thank Bill Coleman, AA4LR, for discussions on TELEBIT's PEP, and the
use of the pilot tone for dealing with multipath effects.        

